Re: GCC's statement expression extension

[Linus Torvalds <torvalds@transmeta.com>]

On Fri, 28 Jul 2000, Marc Espie wrote:
> 
> >How about a new warning instead:
> 
> >	strange.c:14: warning: programmer appears seriously deranged
> 
> >and then let users decide themselves if they really want to use local
> >labels inside expression statements..
> 
> In the long run, I believe that this approach loses.
> 
> Extensions need to have properly defined semantics, and anything that does
> not have fixed down semantics would need to be flagged as a bug, and downright
> not compile at all (not possible in the real world, of course).

Why?

Think about a basic C (and C++) expression:

	++i + ++i

What does the C standard say about the above?

Right. It has undefined behavior. It can return 42. It can format your
harddisk. And the compiler is still strictly conforming, and yes, you get
the occasional "bug-report" about it, but everybody agrees that it _is_
undefined behaviour, and everybody even agrees on _why_ it is undefined
behaviour, and there is really no problem.

What's so different about extensions?

I don't think anybody can really claim that statement expressions do not
fit the C language "spirit". They are _very_ much in spirit with the
language, and work like anonymous inline functions, and allow doing a lot
of very C-like things. It's definitely not an ugly wart on the language in
that sense (basically, what I'm trying to say is that people could imagine
that statement expressions could have been in the original K&R - they are
not fundamentally against the grain of C the way nested functions are).

And yes, like the expression "++i + ++i", there are undefined things. A
branch to within a statement expression is undefined behaviour, and a nice
and polite compiler will tell the programmer that he seems to be doing
something stupid - the same way it might be really nice if gcc actually
warned about "++i + ++i" so that the occasional bug-reports would fade..

> See, the issue is that those constructs only have an implementation-defined 
> meaning that might change from one release to the next because, well,
> because it's not documented, and it's hard to keep track of what other changes
> to that big fat gcc program are going to do.

Statement expressions are extremely well documented. They've been in gcc
(and documented) at least since I started using gcc in -90. And they do
NOT have "implementation-defined meaning that might change from one
release to the next".

Are you suggesting that the "++" operator should be removed because it can
be used in ways that make the result undefined? The result of bad use of
"++" can, right now, change not only from compiler version to compiler
version, but even with the same compiler depending on what the instruction
schedule ended up being (either due to different optimizations or due to
different code _around_ the offending use).

No, you're obviously not suggesting that. But you ARE using the very same
arguments against statement expressions.  You should probably look at your
arguments again.

		Linus