“gcc will quietly break nearly half of all the packages that it compiles”
1–10 of 110 posts
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#2Headline is misleading.
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.
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?
The follow-up email raises this exact point, noting that in the specific example of pointer overflow:
In executions where overflow does not happen, the gcc produced binary will match the behavior of the abstract machine in the C spec.
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.
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.
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#3The article is just complaining about undefined behavior, and what compilers do when they encounter code not written to spec.
Rather than rehashing the arguments for and against it, I'd really recommend anyone interested to read these articles:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#4Since 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.
Compile your test suite with -fsanitize=undefined.
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#5Headline is misleading. 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. But the poster seems to define any change in behaviour as "breaking" code, which is ridiculous. H…
[deleted]
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#6Since when is 40% "nearly half". Can we change the title to something like:
"40% of Debian packages might break if GCC changes the way it handles undefined behavior"
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#7Now that's some flawed logic here:
- Some paper says that 40% of Debian packages have undefined behavior in them.
- gcc's optimizer is sometimes unforgiving w.r.t. undefined behavior (see also: strict aliasing), changing the intended meaning of the code.
- Therefore, it breaks 40% of packages.
And boom, there's your clickbait headline...
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#8Since 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. Compile your test suite with -fsanitize=undefined.
That will catch a tiny part of undefined behavior.
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#9Since when is 40% "nearly half". Can we change the title to something like: "40% of Debian packages might break if GCC changes the way it handles undefined behavior"
More like: Code might break if it depends on undefined behavior. But of course, that might not make it to the front page.
Re: “gcc will quietly break nearly half of all the packages that it compiles”
#10Headline is misleading. 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. But the poster seems to define any change in behaviour as "breaking" code, which is ridiculous. H…
[deleted]
Just read the email.