This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined as trees
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: Gabriel Dos Reis <gdr at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: 13 Dec 2001 23:34:39 +0100
- Subject: Re: Volatile MEMs in statement expressions and functions inlined as trees
- Organization: CodeSourcery, LLC
- References: <Pine.LNX.firstname.lastname@example.org>
Linus Torvalds <email@example.com> writes:
| 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_?
You said that I made up a rule -- which I didn't. Then you claimed
that the behaviour of lvalue-to-rvalue conversion as a "dereference"
was not even supported by the standard. Which is clearly false, as
evidenced by the above quote.
| 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_.
No. It is the result of the assigment "p = 0". Now condiser the
second assigmemt "q = p". To perform that assignment, an
lvalue-to-rvalue conversion is necessariy.
| The special case that affects "sizeof"
I quote the complete bullet for completeness. Not that I think the
special case of sizeof is necessary here.
| In short, the passage you quote in no way argues for your interpretation,
It does. But you, manifestly, do not want to accept facts.
CodeSourcery, LLC http://www.codesourcery.com