Headline is misleading.<p>What's going on here is that the GCC developers feel free to change the generated code for behaviour undefined in the C spec. This means they might alter the behaviour of code since 40% of all packages in Debian (the "half of all packages" mentioned here) contain code whose behaviour is undefined.<p>But the poster seems to define any change in behaviour as "breaking" code, which is ridiculous. How much of that 40% is rare edge cases or similar, such that in reality the behaviour of the code doesn't change in practice?<p>The follow-up email raises this exact point, noting that in the specific example of pointer overflow:<p><i>In executions where overflow does not happen, the gcc produced binary will match the behavior of the abstract machine in the C spec.</i><p>Which means that the cited static analysis, while correctly identifying code containing UB, may not actually have an issue at runtime as the condition may never occur in practice.<p>The real problem is any software that truly relies on undefined behaviour for correct operation (which, I'll bet, is far less than the 40% cited here). That code is fundamentally non-portable to other compilers specifically because each compiler may produce semantically different output.
Now that's some flawed logic here:<p>- Some paper says that 40% of Debian packages have undefined behavior in them.<p>- gcc's optimizer is sometimes unforgiving w.r.t. undefined behavior (see also: strict aliasing), changing the intended meaning of the code.<p>- Therefore, it breaks 40% of packages.<p>And boom, there's your clickbait headline...
The only reasonable thing to say about this was already said upthread of the page, and quoted here:<p>> <i>I have worked on many programs, and whenever I found such a problem (typically called a "portability problem"), where the code was assuming something that the language did not guarantee, I fixed the program rather than bitching about the compiler.</i>
The article is just complaining about undefined behavior, and what compilers do when they encounter code not written to spec.<p>Rather than rehashing the arguments for and against it, I'd really recommend anyone interested to read these articles:<p><a href="http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html" rel="nofollow">http://blog.llvm.org/2011/05/what-every-c-programmer-should-...</a><p><a href="http://blog.regehr.org/archives/213" rel="nofollow">http://blog.regehr.org/archives/213</a>
Inknow people are quick to complain about programmers relying on UB here but this really is a long standing disagreement with the gcc folk. They are language lawyers of the worst sort and do not consider security implications being a point of discussion :(
<i>Since compilers (and by "compilers" I mean gcc mostly) quietly break your code behind your back, you have no way of telling whether you really fixed things or not.</i><p>Compile your test suite with -fsanitize=undefined.
Since when is 40% "nearly half". Can we change the title to something like:<p>"40% of Debian packages might break if GCC changes the way it handles undefined behavior"