[Cryptography] portable, reliable code ... Eventus incertus delendus est

[Ray Dillinger]

On 10/27/2015 09:49 PM, John Denker wrote:

> We agree that it is important to recognize the distinction between
> development and deployment.
>  -- During development, we want to maximize the visibility of
>   any bugs.
>  -- When the product is deployed, we want to minimize the
>   visibility of whatever bugs remain.

> We need a different approach entirely.  During development, we
> need a compiler that provides maximally accurate and informative
> warnings.  By "accurate" I mean that it should not generate
> false negatives *or* false positives.

I think it's worth looking at both the false negatives *and*
the false positives, in all the combinations you can get.  In
the hopes, of course, that they come along with a bunch of
diagnostics that are neither.

I wonder if it's worthwhile to monkey together a makefile
that selects a different compiler, optimization level,
warning levels, error options, and defined-behavior build
flags EVERY TIME ....  or decides 'lint' or some other
analysis tool output is a necessary precondition for
compiling, *that particular time*.  It would sort of
automate something I do haphazardly and by hand every
so often to see what a different compiler or tool thinks
of a particular bug I'm trying to figure out, or of code
I *think* I've successfully debugged.  It's too easy to
be wrong about that.

I don't know if even I'm that masochistic in terms of
testing, and *my* development process is actively a FIGHT
against the compilers to force them to do exactly what I
intend and nothing else.  But it would definitely be
"the right thing to do" w/r/t the goal of producing
portable code.

It might make some things easier because it will
provide different error messages one of which might be
right or useful while others are obscure, wrong, or
"mysterious", or a couple or three of which might
each give ne one necessary "clue" to the same error
while none are informative on their own, making it
possible to figure out more easily by seeing the
different messages in rapid succession.

On the other hand bugs that are exposed by only one or a
few of the builds, or exposed differently by different
builds, will be maddeningly inconsistent in testing, and
I'll definitely want to have a "compiled by" function
that will allow me to ask a buggy version of the program
exactly which compiler (and what version of that compiler
and with what build flags, etc) created it.

Hell, I guess I'll try it. No point doing it haphazardly
and by hand; I might miss something I could have caught.
If it's too obnoxious to cope with, I'll stop.

> Also, generating silly executable code is never the correct 
> way to warn the user.

The *USER*?!  Oh HELL no.  The user gets the most
non-silly executable I know how to build and a
makefile that builds nothing else, with build
options that make a hell of a lot of "undefined"
behavior explicit and checks a hell of a lot of errors
the standard doesn't say you have to check for, like
with stack canaries and array reference ranges, etc.

It's me as the *DEVELOPER* who wants the silliest
executable (or the ten silliest executables) my code
allows; that way whenever one of the compiles or
test scripts fail I know I have to fix the code.

> Eventus incertus delendus est.

Oooh, I like that one.


				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151028/5fedfed1/attachment.sig>