Volatile MEMs in statement expressions and functions inlined astrees

[Linus Torvalds]

On 16 Dec 2001, Alexandre Oliva wrote:
>
> I agree.  They are self-consistent, and, AFAICT, they are in agreement
> with the text of the C++ Standard.  The problem I'm trying to deal
> with is that there is this other reading, that Jason was able to
> explain much better than myself (thanks, Jason!), that makes even more
> sense to me,

I agree, Jasons reading makes perfect sense. In fact, unlike all the other
arguments proposed, I'm definitely willing to concede that Jasons reading
makes the current gcc behaviour standards compliant, however much that
hurts my ego, and however much I'd prefer different semantics.

[ Hey, if you cannot admit you're wrong, you shouldn't be arguing. That
  doesn't make it feel any better ;-]

I just sent off to Jason (and I think you were cc'd) both an explanation
of why I actually care and hate the current "use" semantics, and also
something of an attempt to say that even with his reading of the standard
there may be an acceptable argument for saying that "lvalue-rvalue
conversion" doesn't have to be the dereference.

But after Jasons reading, I definitely won't call the gcc behaviour
non-compliant any more, even if I still think there is a Quality-of-
Implementation issue.


> Unfortunately, taking Jason's reading may take us a few step backs, to
> a question that I think you (Linus) first raised.  Consider the
> following chunks of C++ code:
>
> volatile int i, *p = &i, &r = i;
> //... {
>   i;
>
> Do we want the value stored in i to be read by this expression
> statement?  Why should we read it?

Yes.

Richard already answered it by saying that it is implementation-defined,
and that gcc has chosen to do the lvalue-to-rvalue conversion for simple
expressions (but not for assignment expressions).

In short, it's a special case, and a wart, but that too is not a
compliance issue, only a QoI and sanity issue.

[ Other examples of inconsistencies removed, they all become
  "case-by-case special cases" with Jasons reading ]

Accepting the "rvalue conversion doesn't have to be a dereference" thing
would make all the special cases go away, I claim, simply because you'd be
able to just _always_ do the rvalue conversion (that doesn't have any side
effects on assignments in my readin) on a statement-expression.

Let's see if Jason is at all open to my interpretation of his reading.
He's clearified the discussion so far, let's see if he throws my last
desperate attempt at sanity out ;/

		Linus