[Cryptography] Other obvious issues being ignored?

[Watson Ladd]

On Oct 23, 2015 2:59 PM, "Peter Gutmann" <pgut001 at cs.auckland.ac.nz> wrote:
>
> John Gilmore <gnu at toad.com> writes:
>
> >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.
>
> And how do you know you found and fixed all the problems?  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.
>
> (Also, "portability" != UB, see further down).
>
> >I know this is too much trouble for some people.
>
> Just to provide some data on this, the SOSP paper that inroduced the
STACK UB
> analyser found that UB code occurs in 40% of all Debian Wheezy packages
(that
> use C).  That means that gcc, the worst offender of the lot in terms of
> breaking code (again from the SOSP paper) will break nearly half of all
Debian
> packages when it builds them (the figure of 40% is a lower bound since
STACK
> doesn't do the same level of analysis that gcc does).
>
> I'll just repeat that again, gcc will quietly break nearly half of all the
> packages that it compiles.
>
> One of the examples they give is a pointer-overflow check.  Say you're
> compiling code for x64, Sparc, Power, ARM, whatever.  You include code to
> check for pointer overflows.  Because the Intel 8088, which shipped in
1979,
> eight years before gcc existed and for which gcc has never been able to
> generate code, had a segmented architecture for which the pointer-overflow
> check doesn't work, gcc feels justified in removing the pointer-overflow
> check.

Are you claiming that one cannot write a pointer overflow check in portable
C, or the checks people do write are broken?

>
> This is totally, utterly stupid behaviour for a compiler.
>
> >GCC in particular has a -Wstrict-overflow option that will diagnose code
that
> >is being optimized with the compiler's assumption that it does not cause
> >overflows.
>
> It's pretty much useless, it doesn't warn about situations where it'll
break
> code, and the small number of locations where it warns in my code are ones
> where, no matter how hard I stare at the code, I can't see how any
overflow
> can take place.  So in the few places where it does produce a warning,
it's
> effectively telling me that it's going to break my code due to a false
> positive.  Elsewhere it just silently breaks the code without notice.

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.

>
> >Consciencious programmers can use this option to identify code that was
> >nonportable, so they can rewrite it.
>
> Nonportable != UB.  I can write code that assumes twos-complement
behaviour
> and it'll work the same on any CPU architecture I can get it to.  It's
> completely portable, but according to the C spec it's UB, so gcc feels
> justified in breaking it.
>
> Even if you look at a more architecture-specific level, if I'm compiling
for
> (say) x86-64 then gcc knows that there exists an instruction "multiply
the 64-
> bit value in RAX by another 64-bit value to get a result in the 128-bit
> register pair RDX:RAX", but claims that it doesn't know that adding 10 to
> INT_MAX on the same CPU that it knows every intimate detail of produces a
> negative value.
>
> This isn't "compliance to the C standard", this is just the gcc developers
> being idiots.

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.
>
> Peter.
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151023/c5d8f3d3/attachment.html>