Re: Volatile MEMs in statement expressions and functions inlined astrees

[Linus Torvalds <torvalds at transmeta dot com>]

In article <wvl1yi7vna1.fsf@prospero.cambridge.redhat.com> you write:
>
>However, the C++ standard says
>
>  The result of the assignment operation is the value stored in the left
>  operand after the assignment has taken place; the result is an lvalue.
>
>This seems a pretty clear distinction to me; in C++, *q should be read
>after the store.  In C, it should not.

I don't think you can really strictly argue either way, and it will
probably depend on just how people read it.

When I hear that the result is "...  the value stored in the left
operand ...", I personally would understand it to be that it is the
"value stored", ie it's not the "value reloaded".
 ^^^^^^^^^^^^

See the difference?

If we store 0 to 'x' (whether 'x' is volatile or not), then the "value
stored" is 0.  Always, and without fail. Regardless of what we'd get if
we read something back from 'x'. Agreed?

If we store 0 to 'x', and the standard said that the returned value is
equivalent to the "value of x after storing", then for a volatile 'x' a
compiler would clearly have to re-load the value.

As it is, I would read it as _not_ re-loading the value, but I'll also
admit to it maybe be semantic hair-splitting.

In the C++ standard, the added "after the assignment has taken place"
doesn't seem to matter form a volatility standpoint, but I suspect it
_can_ matter if you have a copy operator for 'x'.  That would explain
why you have the addition there for C++, but not for C.

I don't see why the lvalur/rvalue thing should matter, although I
personally do not really see why C++ would make it an lvalue. It allows
you to say

	(x = y)++;	// Legal C++, illegal in C

but quite frankly, anybody who writes code like that should just be shot
on the spot like the frothing-mad dog he/she is.

>			  In neither language should anyone
>write anything like the example if they're dealing with volatiles.

I think most people would agree, it has even less clear semantics than
"volatile" has normally.

Personally, if I see code like

	a[0] = a[1] = a[2] = ... = 0;

(which some people use for initializers), my mental picture of the C
language definitely says that nothing is ever _read_ in the above, and
that you just see a "series of assignments".  So I would expect to see
only a series of stores, whether 'a' was volatile or not.

But I don't think the language of the standard really can be used to say
that either behaviour is "clearly correct".

I would prefer gcc to change its silly ways (especially as it _seems_ to
be an extra special case in gcc rather than some natural result of how
gcc does assignments), but I don't have other compilers to compare
against, for example. That might give us some indications of how others
have read the standard in the past..

			Linus