February 16, 2026
When the spec hits the fan
What every compiler writer should know about programmers (Anton Ertl, 2015) [pdf]
Programmers vs compilers: stop breaking working code
TLDR: Anton Ertl’s throwback argues compilers use “undefined behavior” to justify risky optimizations that help benchmarks a little but break real code. The comments split between “compilers are overreaching,” “the standards people hold the power,” “just add bounds checks,” and “ditch C for safer languages,” highlighting a battle over speed vs reliability.
A 2015 firebrand PDF from Anton Ertl is back on the feed, and the comments are a battlefield. Ertl’s claim: modern C compilers use “undefined behavior” (when the rules don’t say what happens) as a free pass to rewrite your app, chasing a tiny 1.7% benchmark bump while breaking real, working code. Cue the chorus of “we’ve been here before,” with 2016 and 2019 debates resurfacing via ameliaquining.
The hottest take? zephen calls the whole “we can do anything on UB” mindset “rubbish,” linking a spicy counterargument: “Undefined behavior in C is a reading error”. Meanwhile, Joker_vD drops the cynical truth bomb: power wins—standard writers and compiler authors decide how compilers behave, and that’s that. Animats reduces the drama to basics: most examples are just missing bounds checks, as in “don’t run past the end of your list.” And then Panzerschrek throws the table: use a different language with fewer “gotchas.” Translation: Rust just entered the chat.
The thread turns meme-y fast: “A sufficiently advanced compiler is indistinguishable from an adversary” becomes the day’s slogan; “SPEC-only diet” jokes fly; and someone calls UB Schrödinger’s bug—it both exists and does not until the optimizer “helps.” The vibe? Half fed up, half fatalistic, and 100% entertained.
Key Points
- •The paper argues C compilers increasingly treat code with undefined behavior as fair game for arbitrary transformations, breaking previously working programs.
- •Ertl distinguishes C⋆ (hardware-near practice), “C” (strictly conforming UB-free subset), and Cbench (benchmark-focused subset) to frame the mismatch between programmer expectations and compiler behavior.
- •Measured benchmark gains from UB-based optimizations are small (e.g., 1.017× with Clang-3.1 on SPECint 2006).
- •Converting production C⋆ code to strictly conforming “C” imposes significant developer effort, can increase code size, and may reduce performance.
- •The paper claims focusing on programmer-led, source-level optimizations can yield much larger performance improvements than UB-based compiler optimizations.