<p dir="ltr"><br>
On Oct 23, 2015 2:59 PM, "Peter Gutmann" <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>> wrote:<br>
><br>
> John Gilmore <<a href="mailto:gnu@toad.com">gnu@toad.com</a>> writes:<br>
><br>
> >I have worked on many programs, and whenever I found such a problem<br>
> >(typically called a "portability problem"), where the code was assuming<br>
> >something that the language did not guarantee, I fixed the program rather<br>
> >than bitching about the compiler.<br>
><br>
> And how do you know you found and fixed all the problems?  Since compilers<br>
> (and by "compilers" I mean gcc mostly) quietly break your code behind your<br>
> back, you have no way of telling whether you really fixed things or not.<br>
><br>
> (Also, "portability" != UB, see further down).<br>
><br>
> >I know this is too much trouble for some people.<br>
><br>
> Just to provide some data on this, the SOSP paper that inroduced the STACK UB<br>
> analyser found that UB code occurs in 40% of all Debian Wheezy packages (that<br>
> use C).  That means that gcc, the worst offender of the lot in terms of<br>
> breaking code (again from the SOSP paper) will break nearly half of all Debian<br>
> packages when it builds them (the figure of 40% is a lower bound since STACK<br>
> doesn't do the same level of analysis that gcc does).<br>
><br>
> I'll just repeat that again, gcc will quietly break nearly half of all the<br>
> packages that it compiles.<br>
><br>
> One of the examples they give is a pointer-overflow check.  Say you're<br>
> compiling code for x64, Sparc, Power, ARM, whatever.  You include code to<br>
> check for pointer overflows.  Because the Intel 8088, which shipped in 1979,<br>
> eight years before gcc existed and for which gcc has never been able to<br>
> generate code, had a segmented architecture for which the pointer-overflow<br>
> check doesn't work, gcc feels justified in removing the pointer-overflow<br>
> check.</p>
<p dir="ltr">Are you claiming that one cannot write a pointer overflow check in portable C, or the checks people do write are broken?</p>
<p dir="ltr">><br>
> This is totally, utterly stupid behaviour for a compiler.<br>
><br>
> >GCC in particular has a -Wstrict-overflow option that will diagnose code that<br>
> >is being optimized with the compiler's assumption that it does not cause<br>
> >overflows.<br>
><br>
> It's pretty much useless, it doesn't warn about situations where it'll break<br>
> code, and the small number of locations where it warns in my code are ones<br>
> where, no matter how hard I stare at the code, I can't see how any overflow<br>
> can take place.  So in the few places where it does produce a warning, it's<br>
> effectively telling me that it's going to break my code due to a false<br>
> positive.  Elsewhere it just silently breaks the code without notice.</p>
<p dir="ltr">This paragraph is just wrong. In executions where overflow does not happen, the gcc produced binary will match the behavior of the abstract machine in the C spec. What the compiler is warning about is optimizations only safe if overflow doesn't happen which it cannot determine doesn't ever happen.</p>
<p dir="ltr">><br>
> >Consciencious programmers can use this option to identify code that was<br>
> >nonportable, so they can rewrite it.<br>
><br>
> Nonportable != UB.  I can write code that assumes twos-complement behaviour<br>
> and it'll work the same on any CPU architecture I can get it to.  It's<br>
> completely portable, but according to the C spec it's UB, so gcc feels<br>
> justified in breaking it.<br>
><br>
> Even if you look at a more architecture-specific level, if I'm compiling for<br>
> (say) x86-64 then gcc knows that there exists an instruction "multiply the 64-<br>
> bit value in RAX by another 64-bit value to get a result in the 128-bit<br>
> register pair RDX:RAX", but claims that it doesn't know that adding 10 to<br>
> INT_MAX on the same CPU that it knows every intimate detail of produces a<br>
> negative value.<br>
><br>
> This isn't "compliance to the C standard", this is just the gcc developers<br>
> being idiots.</p>
<p dir="ltr">No, you just refuse to accept the burden of writing C. C programs avoid enumerated bad behavior. Go make a compiler for a safer C instead if you cannot write C correctly.<br>
><br>
> Peter.<br>
> _______________________________________________<br>
> The cryptography mailing list<br>
> <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
> <a href="http://www.metzdowd.com/mailman/listinfo/cryptography">http://www.metzdowd.com/mailman/listinfo/cryptography</a></p>