Volatile MEMs in statement expressions and functions inlined as trees

[Linus Torvalds]

On 14 Dec 2001, Gabriel Dos Reis wrote:
>
> There is no dispute there.  The point is that the standard says the
> result of (p = 0) is an lvalue.  To put the discussion on a sane basis,
> I'm first trying to have you undertanding the implications of the
> assignment
>
> 	q = p;		// #1
>
> -- which basically happens after (p = 0).

You do seem to equate "is an lvalue" with "is identical to".

And I think that's a jump that I'm not willing to take.

I agree that the _lvalue_ of "p = 0" is the same as the _lvalue_ of "p".

And you make that lvalue equality imply that the rvalue _has_ to be the
same, so you make that to mean that "q = p = 0" _must_ imply "q = p" after
the assignment. Because the _right_ side of an assignment uses the
_rvalue_ - that's where the "r" comes from, after all.

Right? This fundamentally the thing you are arguing, no?

> | So it clearly and unambiguously says that "q gets the result of the
> | _assignment_".
>
> And it also says that the result of the assignment is an lvalue and
> *you* are claiming it is an rvalue.  It is not me who is changing the
> rules.

I'm saying that rvalue and lvalue are BOTH valid things, and they BOTH
exist.

The _rvalue_ of "p = 0" is 0.

The _lvalue_ of "p = 0" is "p".

See what I'm trying to say?

> I parse the *complete* sentence which ends with "the result is an
> lvalue".

No. You parse the _last_ part of the sentence, and you seem to overlook
the other part that says "the result is the value stored", and because of
your lvalue-centric views, you try to explain that away.

You overlook it, because you find it inconceivable that there are multiple
"dimensions" to the result, and you cannot reconcile the "value stored"
with the "lvalue" part.

I'm saying that BOTH parts are true, because there are two sides to the
coin.

When we do

	q = p = 0;

we have

	q = (rvalue) ( p = 0 );

which is equivalent to

	p = 0;
	q = 0;

However, when we do

	(p = 0) = 1;

then "p = 0" is used as an _lvalue_, and you actually get

	(lvalue) (p = 0) = 1;

which thus is equivalent to

	p = 0;
	p = 1;

And note how both are entirely consistent. And in particular, note how
this is _entirely_ consistent with the _whole_ sentence, which is that the
_result_ of an assignment is the value stored (0), while the result is
_also_ a lvalue (and using the result _as_ a lvalue will access "p").

YOUR argument is that "p = 0" is an lvalue, and by ignoring the "result is
the value stored" part, you say that "the value of an lvalue is the value
of the thing it points to", so you get

	q = p = 0;

and as your "p = 0" is an lvalue (and nothing _but_ a lvalue), you take
this to mean that the value of "p = 0" _must_ be the value of p, so you
come to the conclusion that "q = p = 0" is the same as "p = 0; q = p;".

But that is _NOT CONSISTENT_ with that pesky middle part of the quoted
sentence. You just ignore the inconsistency, because you're not willing to
give the rvalue any real status.

I, however, am part of the radical "free the rvalue" group, which asks for
equal rights for rvalues everywhere, and we (a very select group indeed)
claim that rvalues can exist side-by-side with lvalues, and do not always
happen as a result of a dereference. Sometimes those rvalues happen as a
result of a _assignment_ too.

I'm the Malcolm X and the Martin Luther King Jr of rvalues, and I'm saying
that my egalitarian world-view does not have the inconsistencies that your
lvalue-dominated world-view has. So I don't have to ignore _either_ part
of the hard-to-parse sentence.

		Linus "I have a dream..." Torvalds