Re: Volatile MEMs in statement expressions and functions inlinedastrees

[Linus Torvalds <torvalds at transmeta dot com>]

On 15 Dec 2001, Alexandre Oliva wrote:
>
> > Also, I still claim that the standard CLEARLY SAYS (5.17.1):
>
> >   "..the result of the assignment operation is the VALUE STORED.."
>
> > (emphasis mine).
>
> but that, after the assignment is performed, and the result is
> actually an lvalue, so it can be asserted that the value stored was
> written into lvalue, and it can be only assumed that reading it back
> would get the same value back,

That's not true, and you know it.

It can NOT be assumed that "reading it back would get the same value".

Not for a volatile expression.

I can give you a test-case where it is not true. The asserted test-case
looks something like

	#define nonmapped_pci_space_offet (0xff000000)

	void *p;
	volatile int *ip;
	fd = open("/dev/mem", O_RDWR);
	p = mmap(NULL, PAGE_SIZE,
		PROT_READ | PROT_WRITE,
		MAP_SHARED,
		fd,
		nonmapped_pci_space_offset);
	ip = (volatile int *)p;

	assert ((*p = 10) == 10);

and I claim that

 (a) according to the C++ standard, that assert must NEVER fire
 (b) with the current gcc (and your proposal) it _will_ fire on most PC's
     (it assumes that physical address 0xff000000 is not RAM, and that it
     doesn't have ay PCI devices behind it, in which case most hardware
     will always return 0xffffffff on reads).

> but it's not guaranteed that converting
> the lvalue resulting from the assignment, whose stored value was the
> result of the rvalue of the assignment, is to be used should the
> rvalue of the lvalue be accessed.  It's quite reasonable to do so, but
> I don't fully agree it's mandated by the Standard.

The _what_ do you claim that "value stored" thing actually means?

I do not see ANY other meaning than basically a language guarantee that
the above assert never fires. It doesn't matter that "volatile" is
involved, it doesn't matter what the address is, the only thing that
matters is that we stored a value to an lvalue, and the return value of
that assignment was something _else_ than the "value stored".

There are no "gray areas" here.

> That depends on whether the function returns a reference (lvalue) or
> not (rvalue).

It does NOT.

The standard says that it returns _the_value_stored_.

The fact that it is an lvalue means that you can do other things with it,
like take its address.

The fact that it is an lvalue does NOT mean that you can ignore the rest
of the sentence, and override it.

The meaning of "result of the assignment is the value stored" is not open
to much debate. I claim that if I can generate a valid integer pointer,
and

	(*ip = 10) != 10

then THE COMPILER IS BUGGY by virtue of that one sentence. No
"implementation defined" issues anywhere in sight. The standard is clear
and unambiguous.

I further claim that NOWHERE does the standard say that the "lvalue to
rvalue conversion" is an "access". Show me. I've quoted the passage, and
I've pointed out that nowhere in the definition of "lvalue-rvalue"
conversion does it _ever_ say anything about accessing the object
associated with the lvalue.

Yet your WHOLE POINT hinges on that supposed access. The _only_ argument
you have against the fact that the standard says that the value returned
is the same as the value stored is the fact that there is a "lvalue to
rvalue" conversion.

I'm claiming that that lvalue-to-rvalue conversion _has_ to convert to the
value stored AND NONE OTHER, because if it ever converts to anything else,
then you've violated the standard on assignments.

QED.

> The way I read that passage, I take it as ``the result of the
> assignment operation is [most often] the VALUE STORED..., but it's an
> lvalue.''               ^^^^^^^^^^^^ introduced by myself

Yeah, sure, you can change the language of the standard any way you like,
but that does not make it so.

Face it, it does not say "most often". It says that the result _IS_. Not
"may be" or "might be related" or "kind-of-looks-like" or "is the
de-reference of the left side".

But if you want to debate the meaning of the word "is", then you're in
great company, and I hope your intern looks better than the intern of the
last person who tried it.

		Linus