This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined astrees
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: aoliva at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Dec 2001 17:34:48 -0800
- Subject: Re: Volatile MEMs in statement expressions and functions inlined astrees
- Newsgroups: linux.egcs.patches
- References: <Pine.LNX.firstname.lastname@example.org>
[ Damn, our mail server is bouncing up and down today. ]
In article <email@example.com> you write:
>Actually, I think the basic `lvalue = rvalue' is exactly the right
>thing to do according to the Standard,
I agree, I just couldn't find the sentence that actually _says_ so. The
assignment operator stuff talks almost exclusively about the left side,
and doesn't much bother to even mention the right side.
> with lvalues decaying to
>rvalues in the right-hand operand, again, as dictated by the C++
Agreed. Regular "lvalue->rvalue conversion", section 4.1.
> The decaying does involve dereferencing
But this is where I _disagree_.
Note: the standard actually mentions "dereferencing" only for iterators
and for pointers, and it is not mentioned anywhere else. In particular,
it is _not_ mentioned in 4.1.
The standard calls getting the value (what you and me would usually call
dereferencing) "accessing", and look again at section 4.1.
Yes indeedy, it _nowhere_ states that the "lvalue->rvalue conversion"
would be an access.
In fact, the standard very clearly skirts the issue by in all of 4.1
talking about "conversion", except for the one special case where it
actively _forbids_ accessing (ie the sizeof case).
So the only time the standard mentions "access", it mentions it only in
order to actively _forbid_ it, probably because of the issue of accesses
that can trap (ie "sizeof(*p)" must not trap, even if 'p' doesn't have a
valid pointer value).
Go on, read 4.1 yourself. It's not that long. It talks about
"converting" several times, but does not in any way try to imply that
"conversion" to a rvalue would always be an access.
And again, note that assignments are special. Assignments _set_ the
value that you would access.
In fact, the only sentence in the rvalue conversion thing that actually
says what the _value_ is, is
"The value contained in the object indicated by the lvalue is the
And think about what an assignment _is_. It sets the value. The value
we store to the object _is_ fundamentally the "value contained withing
the object" at the time of the assignment.
And reading the value back later can result in a _different_ value than
the one at the time of the assignment.
In short: NOWHERE does it say that the "lvalue->rvalue conversion"
implies an access. In fact, I'd say that the language is worded to
_avoid_ the "access" notion. I do not see anything that requires it,
and I do have arguments against it.
Where do people get the "lvalue->rvalue" == "dereference" notion?