Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.std.c |
| Subject | Re: Description of "." operator |
| Date | 2013-01-05 23:51 -0800 |
| Organization | None to speak of |
| Message-ID | <lnmwwm4umo.fsf@nuthaus.mib.org> (permalink) |
| References | <lntxrxnufa.fsf@nuthaus.mib.org> <kcb58h$s8g$1@dont-email.me> |
[Something strange happened to the non-ASCII characters in your article.
I haven't taken the time to fix them.]
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.
>> 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
>> 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.
`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.
> 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.
>> 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.
> 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.
>> 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.
> Interesting stuff!
>
> - Shao Miller
--
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
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