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

Groups > comp.std.c > #1817

Re: Description of "." operator

Show all headers | View raw

On 1/6/2013 02:51, Keith Thompson wrote:
> [Something strange happened to the non-ASCII characters in your article.
> I haven't taken the time to fix them.]
>

D'oh.

> Shao Miller <sha0.miller@gmail.com> writes:
>> On 12/7/2012 21:34, Keith Thompson wrote:
>>> N1570 6.5.2.3p3 says:
>>>
>>>       A postfix expression followed by the . operator and an identifier
>>>       designates a member of a structure or union object. The value
>>>       is that of the named member, and is an lvalue if the first
>>>       expression is an lvalue.
>>>
>>> Consider the use of the word "object" in the first sentence.
>>
>> 3.1:
>>
>>     "1 access
>>        <execution-time action> to read or modify the value of an object
>>      2 NOTE 1 Where only one of these two actions is meant, "read" or
>> "modify" is used.
>>      3 NOTE 2 "Modify" includes the case where the new value being
>> stored is the same as the previous value.
>>      4 NOTE 3 Expressions that are not evaluated do not access objects."
>>
>> 3.15:
>>
>>     "1 object
>>        region of data storage in the execution environment, the contents
>> of which can represent values
>>      2 NOTE When referenced, an object may be interpreted as having a
>> particular type; see 6.3.2.1."
>>
>> 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.

>>> 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?

>>> For example:
>>>
>>>       struct pair { int x; int y; };
>>>       struct pair func(void) {
>>>           struct pair result = { 10, 20 };
>>>           return result;
>>>       }
>>>       ...
>>>       int y = func().y;
>>>
>>
>> 6.5.2.2p5:
>>
>>     "If the expression that denotes the called function has type pointer
>> to function returning an object type, the function call expression has
>> the same type as that object type, and has the value determined as
>> specified in 6.8.6.4. Otherwise, the function call has type void."
>>
>> 6.8.6.4p3:
>>
>>     "If a return statement with an expression is executed, the value of
>> the expression is returned to the caller as the value of the function
>> call expression. If the expression has a type different from the return
>> type of the function in which it appears, the value is converted as if
>> by assignment to an object having the return type of the function.160)"
>
> That doesn't imply that there's an object.  The value is converted *as
> if by assignment to an object*, meaning simply that the conversion
> follows the same rules followed by assignment to an object.
>

Agreed.  (No claim that there was.)  But a tiny note for random readers: 
It's only converted, as if by assignment, for the case of a different 
type.  (I'm sure you already know that.)

The pieces quoted were only offered for their relevance to the 
situation, but not as a response to the very interesting consideration 
that you've shared in this thread.

> `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.

>> 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?

>>> 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.

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:

   void ex2(int y) {
       int x;
       x = y;
     }

The "lvalue conversion"[6.3.2.1p2] happens to 'y', which is a similar 
process to the previous example, except that we can certainly access 
_the_same_ object again and again, because we have this "locator value".

"Locator value" makes me think of aliasing, easily repeatable access and 
the qualifications[6.7.3] of the object, rather than a notion of "lvalue 
== object".  While "lvalue" _certainly_ requires an object, that we 
don't see a requirement of a "value == object" in most places allows an 
implementation some freedom:

   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.

>> And p7 is pretty close to your example.
>>
>>> Shouln't the phrase "a member of a structure or union object" be "a
>>> member of a structure or union *value*"?
>>
>> Unless the intention is to actually define it to be an object, where
>> perhaps 6.2.4 and 6.5p7 and who knows where else need some adjustment.
>
> Perhaps, but the acknowedgement that the left operand needn't be an
> lvalue argues otherwise, I think.
>

(Argued against above.  However, I don't claim either interpretation is 
absolutely right.  I don't know.)

>>> If not, in the example code above, what object is being referred to?
>>> ("result" no longer exists after the function returns.)
>>
>> If "lvalue" is well-thought-of as "an object locator value," then
>> perhaps the answer is: An object we can't locate?  Well wait a minute...
>> that's what you're asking... :)
>
> And my answer is that *no* object is being referred to.
>
>> It seems a bit similar to the case with 'register'-specified objects,
>> except that there are lvalue expressions possible with these latter;
>> neither apparently have programmer-accessible locations.
>
> But register objects are still objects, and can clearly be referred to
> by lvalues.

Here's another idea:

   #include <stdarg.h>
   #include <stdio.h>

   typedef struct { int x; } s_foo;

   void ex3(int n, ...) {
       va_list ap;

       va_start(ap, n);

       printf("%d\n", va_arg(ap, s_foo).x);

       va_end(ap);
     }

   int main(void) {
       s_foo foo = { 42 };

       ex3(0, foo);

       return 0;
     }

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].

- Shao Miller

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