This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC's statement expression extension


I did not think you would be so daft as to take ++i behavior into this
discussion.  C programmers know about it, unless they are fairly stupid.

What I was arguing about to start with is NOT expression statements per se, 
but some aspects of it which don't work, and that can bring some more such 
nonsense to C.  And this is something C programmers usually do not know 
that much about, since this is not a part of standard C. 

I am not really a fan of the `hey, I know what I'm doing. Stupid compiler,
shut up.' school.  Especially recently.

As compilers get better.

As rules get more complicated.

And there's also the fact that you always, always, find people out there
who play fast and loose with the rules, when the compiler allows it.

And it breaks software.

Sometimes important software.
And in some cases, people get stuck with an older compiler version, as the
broken software is very popular...

I've seen some fairly atrocious code. I'll protect the guilty, and not give
any names.  But having more warnings and errors is a good thing.

As far as extensions go, there is one very important difference: they are 
not part of the standard.  As a compiler implementor, you can draw the line
where you please, including erroring out on nonsense that accidentally happens
to do something. Whereas the C standard needs to be implemented, including
nonsense when it contains nonsense.

There is one very good point about being steady about it: instead of 
harboring further problems linked to not well-defined semantics, it is 
possible to just stop compiling when the result becomes ill-defined.
If an extension of the extension would be useful, then it will be 
discussed, and implemented. 

There will be PRESSURE to do that. 

Pressure which simply does not exist if that aspect of the existing 
implementation does useful, undocumented things.  As people will use it as
is. 

And then the pressure is to keep the status-quo: go on supporting a 
non-feature that was an accidental result of side-effects in an 
implementation aiming at other actual features.  Which may be poorly 
thought-out, and detrimental to further progress.

(It's probably fair to take further discussion off the list at this point, btw).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]