I particularly like this quote from Regehr's blog post:

"A sufficiently advanced compiler is indistinguishable from an adversary."

I remember reading that the LLVM compiler emits invalid opcodes our stops compilation when hitting undefined behaviors. That would actually be a good thing when writing portable code our even in the presence of dead code elimination.

-- Baruch

Code that always invokes undefined behavior is the easy case. The kind of code that John Regehr writes about is code that merely may invoke undefined behavior and the problem is that it is everywhere because C has so much undefined behavior. For example, integer overflow during arithmetic is undefined behavior but in most cases a compiler can't definitively prove either that it always happens or that it never happens.

I didn't see much about this Regehr's blog, at least the first page, so you might find these slides interesting:

http://www.google.com/search?q=%22dangerous+optimizations+and+a+loss+of+causality%22

(I can't link the PDF directly because the only way I know to find it is google, and google won't show me the direct link, and neither does my browser.)

The argument here is right back to your old discussions of standards vs. de facto standards etc.

Compiler writers (especially gcc) have decided that the written standard is the standard, and they are allowed to do anything it allows (what Seacord calls the "total license model").

People who have good reason to use C (I'd have once called us "system programmers", but the class of what C is used for is more complicated now) believe there is a de facto standard way that this stuff has worked and has always worked (what Seacord calls the "hardware model"). We consider the compiler writers' appeals to the standard as allowing this deviation as (a) terrible for compiling existing code, (b) terrible for writing clear and correct code (e.g. the integer arithmetic overflow stuff, or gcc's strict type aliasing analysis), and (c) a hideous abuse of the system because practicing and highly-skilled C programmers do not appear to be represented on the C standard committees, and so the fact that the standard allows the compiler writers to do what they're doing isn't even a reasonable defense of the situation when you view the whole ecosystem.

And it's weird, because you'd think compiler writers' goal would be to help people write fast and correct code, not to get the maximum possible result on SPEC benchmarks, but the latter priority is the only thing I can think of to explain their behavior.

I'm also reminded of an incident from perhaps a year ago, for which I cannot figure out the right thing to google search, in which someone who was closely following the new C++ standards noticed that by carefully analyzing the language of certain parts of the C++ standard, and carefully analyzing the language of a particular part of the STL (standard template library), an accompanying but separate standard, putting those two pieces together implied a strong requirement on any object that could be used in certain STL-ish contexts. This was a requirement that people were very interested in being able to rely on objects to have, but everyone believed it could only be required by contract--it wasn't require by the language--but now, he argued, it would in fact be invalid C++ for anyone to ever pass you an object of that type in this sort of application.

I don't know what the long-term fallout about this was (whether people agreed or disproved that this was implied by the standards), but my immediate reaction was 'that's a terrible thing to assume, obviously your normal highly-skilled programmer isn't going to have done this careful analysis, that's a stupid way for a spec to work'. (Obviously if the result were well-publicized, you could then expect them to know it, but that's closer to a de facto standard anyway.)

I think a direct URL is Dangerous Optimizations and the Loss of Causality. It's certainly interesting reading.

I believe that most of the interesting John Regehr blog entries (for this purpose) can be found in his compilers category, although it looks like his major series on undefined C behavior was a while back; a classic couple of entries are his A Guide to Undefined Behavior in C and C++, Part 1, Part 2 and Part 3. As a bonus you'll get interesting entries like this discussion of how to get compilers to correctly optimize certain sorts of casting and C and C++ Aren’t Future Proof.

(He sometimes points to other interesting blog entries, like What Every C Programmer Should Know About Undefined Behavior #2/3. Why yes, I am noting down URLs here partly for my own later reference.)

Google won't show me the direct link

Google Tracking-B-Gone will help you. (GreaseMonkey script, rewrites the SERP URLs to remove the Google redirect.)

—Aristotle Pagaltzis