Messages in this thread | | | Date | Tue, 29 Jul 2008 09:44:17 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: linux-next: build failure |
| |
On Tue, 29 Jul 2008, Linus Torvalds wrote: > > [...] since statement expressions are gcc > extensions, and as such the gcc people could make up any semantics they > want to them, including just defining that a statement expression with > an lvalue value is the same lvalue rather than any temporary).
In fact, that does seem what gcc-4.x does. The way to tell is to do
const int *x;
({ *x }) = 1;
and it's (a) legal (assignments to non-lvalues wouldn't work) and (b) gives a nice warning about assignment to read-only location, which in turn implies that the compiler properly just peeled off the de-reference even though it was inside the statement expression.
IOW, at least in gcc-4.3 (and apparently in earlier gcc-4 versions, but not in gcc-3.4.5), a statement expression with an lvalue return value _is_ actually an lvalue.
But that also means that there is no difference what-so-ever between (x) and ({ x; }) in gcc-4. And in gcc-3 there is, because apparently in gcc-3 a statement expression is never an lvalue (which is actually the sane thing, imho).
Linus
| |