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

Groups > comp.std.c > #1815

Re: Description of "." operator

Show all headers | View raw

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"

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

> 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)"

Could it still be a region of data storage in the execution environment?

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

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.

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

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.

Interesting stuff!

- 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