[Cryptography] Other obvious issues being ignored?

Watson Ladd watsonbladd at gmail.com
Tue Oct 27 06:36:57 EDT 2015


On Sun, Oct 25, 2015 at 2:46 PM, Ray Dillinger <bear at sonic.net> wrote:
>
>
> On 10/23/2015 01:58 AM, Peter Gutmann 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.
>>
>
> But writing code that's acceptable to gcc is important for two
> reasons. First, if you don't have a particularly "adversarial"
> compiler, you will never find the problems in your code where a
> silly or utterly useless interpretation of what you wrote, is
> allowed by the standard. gcc specializes in finding the silliest
> or most utterly useless permissible interpretation of your code,
> so making it your usual compiler makes that your testing baseline.
> Gcc is a sort of worst-case nightmare scenario of the language
> standard. Code that works on gcc will need very little maintenance
> in the future, because later language standards are likely to make
> a difference only to code that the current standard allows silly
> or useless interpretations of - which you can't write if gcc is
> one of your regular test compilers - and no other compiler
> working within the current standard will ever find more excuses
> to produce silly or useless executables.
>
> Second because when you release code to clients, they're
> going to use "whatever" compiler to compile it, and they're
> going to blame YOU, not the compiler devs, if their executable
> does silly or useless things. No matter if they've signed off
> on the build process and makefiles you provided, this will
> still happen. Pointing at that part of your contract can get
> you paid, sure, but they will still be miffed at you about it.
> Because they're not likely to find a compiler that will
> produce a sillier or more useless interpretation of your code
> than the one you test every time you compile with gcc, the
> odds are in your favor.
>
> Alas, they may find one that is *differently* silly or useless
> and thus exposes bugs that gcc didn't. But that's why you test
> builds with different compilers before you deliver code, and
> that's why your contract includes the build process as well as
> the source.
>
> Anyway, my problem is not with compilers that bite me whenever
> the standard allows them to, because every one of those bites is
> legitimately a bug in my code given that wimpy damn standard;
> my problem is with wimpy damn standards that allow them to bite
> me a lot.

So go use Java, which defines 2's complement semantics for integer
overflow. Or Go, or Modula-2, or Ada, or half a dozen languages without C's
issues here, and that can fix lots of other issues (bound checks, etc).
There's no reason to write emails complaining about this when you can fix
the problem instantly.

Or you could learn how to write overflow checks correctly. We don't
complain about null pointer dereference being a bad idea or manual memory
nanagement, we change languages instead. Use tools which ensure UB won't
happen like FRAMA.

Also there is no such thing as a compiler that doesn't optimize. Toy
compilers might not do sophisticated dataflow analysis, but they certainly
will do graph coloring and omit redundant stores and loads.

TL;DR use Ada.
>
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151027/add88f5c/attachment.html>


More information about the cryptography mailing list