Volatile MEMs in statement expressions and functions inlined as trees

Linus Torvalds torvalds@transmeta.com
Thu Dec 13 13:39:00 GMT 2001


On 13 Dec 2001, Gabriel Dos Reis wrote:
>
> |  - made-up-rule #2: lvalue->rvalue conversion is a dereference
> |
> | 	This "rule" is _also_ not supported by any standard I have ever
>
> 4.1/2
>   The value contained in the object indicated by the lvalue is the
>   rvalue result. When an lvalue-to-rvalue con-version occurs within
>   the operand of sizeof (5.3.3) the value contained in the referenced
>   object is not accessed, since that operator does not evaluate its
>   operand.

And the above supports your position exactly _how_?

I would say that it only strengthens my case.

"The value contained in the object indicated by the lvalue"

Remeber, the lvalue in question is an _assignment_.

And then you go back to the assignment rules, and realize that the "value
contained in the assignment" is in fact the value assigned.

The special case that affects "sizeof" (and, in gcc extensions also things
like "typeof" etc) doesn't change anything, it only says that the operand
isn't even evaluated, nor do we care about what the "value contained" in
the operand is. So in that case, we have

	sizeof(p = 0);

where the assignment won't even be done, because the operation isn't
evaluated. That is entirely consistent with the rules.

In short, the passage you quote in no way argues for your interpretation,
IMNSHO. Quite the reverse. It says that the lvalue->rvalue conversion is
about getting the _value_ contained in the expression. It does not in ANY
way imply "loaded from the memory location pointed to by the address of
the expression".

		Linus



More information about the Gcc-patches mailing list