Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1823

Re: Description of "." operator

Show all headers | View raw

Shao Miller <sha0.miller@gmail.com> writes:
> On 1/6/2013 02:51, Keith Thompson wrote:
[...]
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> On 12/7/2012 21:34, Keith Thompson wrote:
[...]
>>> 3.19:
>>>
>>>     "1 value
>>>        precise meaning of the contents of an object when interpreted as
>>> having a specific type"
>>
>> Like too many of the standard's "definitions", that's incomplete.  There
>> can be values that have nothing to do with the contents of an object.
>>
>
> Actually, I took it to have emphasis on "meaning."  So I agree with you, 
> values exist independently of objects.

Right -- and that should apply to struct types as well as to scalar
types.  At least, I can't think of any good reason why it shouldn't.

>>>> An expression of struct type doesn't necessarily refer to an *object* of
>>>> that type.
>>>
>>> Why not?  Is it because of:
>>>
>>>     - The possible lack of a definition for the lifetime[6.2.4]?
>>>     - The possible denial of accessing its stored value via an lvalue
>>> expression[6.5p7]?
>>
>> Why should there be an object?  The expression 42 is of an object type,
>> but it doesn't refer to any object
>
> I don't know if there is or not, but it does boggle me a bit to imagine 
> that the values _must_ be out-of-band relative to the definition of 
> "object."  But if we imagine for the sake of discussion that '42' does 
> have an associated object, do the two points above stand in the way of 
> that scenario?

If we imagine that the constant `42` must have an associated object,
then I think we're talking about something other than C.  I don't know
what meaningful conclusions can be drawn from such an assumption.

[...]

>> `return 42;` in a function returning double doesn't convert the int
>> value 42 to an object of type double; it merely converts it to a value
>> of type double.  IMHO it should be the same for struct types as for
>> scalar types.
>
> You must be emphasizing the "no object involved" bit, rather than the 
> "converted" bit, since we don't often convert non-scalar values.

Actually I don't think we *ever* convert non-scalar values, except
perhaps for a handful of special cases ((void)whatever, and the
implicit conversion of array and function expressions to pointers).

>>> Could it still be a region of data storage in the execution environment?
>>
>> Evaluating `2 + 2` may well use some storage for the operands and/or the
>> result, but there's no object in the abstract machine, just values.
>
> Does the Standard say that somewhere, or does that statement stem from a 
> lack of discussion about it in the Standard?

Lack of discussion.

>>>> And the second quoted sentence seems to explictly acknowledge that the
>>>> left operand needn't refer to an object.
>>>
>>> I think one has to equate lvalue with object to draw that conclusion,
>>> right?  If an lvalue expression locates an object, could a non-lvalue
>>> expression still be associated with a region of data storage, without
>>> location concerns?
>>
>> If it's associated with a region of data storage, i.e., with an object,
>> doesn't that mean that it designates an object?  And if it designates an
>> object, it's an lvalue.
>
> 6.3.2.1p1:
>
>    "An lvalue is an expression (with an object type other than void) 
> that potentially designates an object;64) ..."
>
> So I don't it's 100% clear, unless it had said "any" instead of "an".
> If
> expression-with-object-type-other-than-void-that-potentially-designates-an-object
> is a set, then lvalue could be a subset.

I'm assuming that the definition of lvalue is exhaustive -- which IMHO
it certainly *should* be, but given the standard's track record perhaps
that's overly optimistic.

> But I interpret it the same way you do, except that I use the 
> [non-normative] foot-note to put an emphasis on "locator value".
>
> Given:
>
>    void ex1(void) {
>        int x;
>        x = 42;
>      }
>
> It's possible to imagine '42' as being an object that the programmer 
> cannot "locate," but that is still accessed for its value.  Then in:

Sure, you can imagine that, but it hardly seems necessary or useful.

A function implementation may be stored in a region of memory, but that
doesn't make it an object.  The implementation of malloc() and free()
probably stores metadata in memory, but I wouldn't call those C objects
either (if, for example, the standard library is implemented in
something other than C).

[...]

>    void ex1(void) {
>        int x;
>        x = 42;
>      }
>
> '42' _needn't_ be an object, as the value of 'x' could be set to zero, 
> then incremented 42 times.  But when we see the sentence of your 
> original consideration waaay up above, we could imagine that to define 
> that a struct value _always_has_ an associated object; just possibly one 
> whose "location" isn't particularly meaningful.

A value of a struct type that happens to be sizeof (int) bytes can
be constructed without needing an "object" as easily as an int value
can be.  A larger struct value is more likely to require a chunk of
memory to build it, but there shouldn't be a fundamental difference
based on the size.  The "object", if any, isn't accessible (as an
object) to the program, and I argue that it *isn't* an object as
far as the abstract machine is concerned.

[...]

> I don't think 'va_arg' yields an lvalue, but if:
>
>    "A postfix expression followed by the . operator and an identifier 
> designates a member of a structure or union object. ..."
>
> should be taken to mean that there definitely _is_ an object involved, 
> then I'd still wonder about its lifetime[6.2.4] and how we are able to 
> access its value without an lvalue[6.5p7].

Arrays values don't work properly without having objects associated
with them; see C11's introduction of "temporary storage duration".
I don't think structs have the same issues.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-07 18:34 -0800
  Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-08 10:43 -0800
    Re: Description of "." operator Jens Gustedt <jens.gustedt@loria.fr> - 2012-12-10 00:35 +0100
      Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-09 20:02 -0800
  Re: Description of "." operator jgk@panix.com (Joe keane) - 2012-12-09 23:34 +0000
    Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-09 20:00 -0800
  Re: Description of "." operator Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 23:32 -0800
    Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-21 02:08 -0800
      Re: Description of "." operator Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-21 09:18 -0500
        Re: Description of "." operator Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 08:45 -0800
      Re: Description of "." operator Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 08:37 -0800
  Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-06 01:23 -0500
    Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2013-01-05 23:51 -0800
      Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-06 13:49 -0500
        Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2013-01-06 22:12 -0800
          Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-17 23:19 -0500
            Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-18 20:47 -0500
              Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2013-01-18 20:14 -0800
              Re: Description of "." operator jgk@panix.com (Joe keane) - 2013-01-20 20:07 +0000
                Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-20 15:36 -0500

csiph-web