Date: Fri, 9 Oct 2015 13:55:41 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Specification of a modular crypt format (2)

[Several replies combined into one, since I'm not sure how on-topic it still
 is :-)].

Alexander Cherepanov <ch3root@...nwall.com> writes:

>Did they already implemented C99?

2013 (haven't checked 2015 yet) supported a lot of C99, but since I have to
support pretty much every compiler under the sun I can't use C99 anyway.

>[ftrapv]
>
>Yes, a nice option. Beware though that it doesn't work in 64-bit mode for gcc
>at least up to version 4.9:

In any case the ftrapv behaviour (crash the program) is worse than useless,
when you've got code that checks for overflows and handles them you want the
checks to not be removed, not to be given the option to have your program
crash.  So the difference between gcc and gcc -ftrapv is that the former
produces braindamaged behaviour, the latter does the braindamage and then
crashes your program as well.

>http://blog.regehr.org/archives/213

Oh, they quote the basketball analogy.  For people who haven't seen this, it
draws the following analogy for UB:

  Somebody once told me that in basketball you can’t hold the ball and run. I
  got a basketball and tried it and it worked just fine. He obviously didn’t
  understand basketball.

What they omit to mention is that if you try this, you expect the umpire to
declare it an infringement and confiscate the player's golf bats (from which
you can deduce that my knowledge of sportsing, see
http://vectorbelly.com/electrical177.html, leaves something to be desired).
You don't expect an air strike to take out the stadium, killing everyone
inside (gcc/ftrapv).

>Maybe just fix bugs in the code?:-) Seriously, some recent tools make it
>easier. First of all, run your test suite with valgrind, Address Sanitizer
>and Undefined Behavior Sanitizer. Raise code coverage with a fuzzer (e.g.
>American Fuzzy Lop) and, perhaps, KLEE.

I already do all of that, and also cppcheck, clang, Coverity, Klocwork,
Prefast, and some others.  Problem is that (a) gcc breaks code faster and more
effectively than any analyser can find things and (b) most developers don't do
this, which means they can't even try to work around gcc's problems.  I hate
to think how much code out there is broken by gcc, with no-one the wiser...

>Then use tools like Clang Static Analyser and cppcheck. Then proceed to
>STACK[3], Frama-C etc.

That really doesn't scale.  I already perform what I'm sure most developers
would agree is an insane amount of analysis on my code, and still can't catch
all the things that gcc does to it.  What's worse, no matter how much analysis
I perform, I can never be sure that I've managed to counter all the things
that gcc will end up doing to it.  I can't imagine that any project built
under time/commercial pressures could afford to invest this amount of effort
into fighting what gcc does to their code.

(Some time ago, one of the leads at Coverity said at a talk that they invest
something like 80% of their effort not into creating more code to find
problems but doing things like getting rid of false positives due to warnings
that are technically valid but that most people would agree are unnecessary.
In other words they recognise that Doing the Right Thing helps users more than
quoting dogma at them and breaking things like the gcc folks do.  Other
vendors like Fortify handle this a bit differently, they rank things by
severity but don't put so much effort into FP suppression, so when you look at
the lower grades of warnings you get so many of them that you mostly end up
just skipping them.  Not saying that this is necessarily a bad thing, but I
prefer the Coverity approach to the Fortify one).

>just start with the usual suspects

Already doing that, but it's pretty sad that I need to add -fdont-break-my-code
flags just to get the compiler to not break my code.  And just because you and
I know that these flags exist doesn't mean that everyone else does, so they'll
still get caught

Peter.

Powered by blists - more mailing lists