[Cryptography] [FORGED] Re: How programming language design can help us write secure crypto code

[Ray Dillinger]

On 10/31/2015 09:20 PM, Peter Gutmann wrote:
> Thierry Moreau <thierry.moreau at connotech.com> writes:
> 
>> Isn't this a basic precaution from the compiler *user*?
> 
> Not if the documentation doesn't tell them what the annotation will do.  As
> I've already said twice now, the various people I've talked to about this
> assumed that what the annotation did was warn about inadvertent null pointer
> use.  It's not a large sample, but of that sample, 100% assumed from reading
> the docs that it did more or less the opposite of what it actually does.  This
> implies that either the compiler or the docs need to be fixed.  The gcc
> developers have chosen to do neither.
> 

But that ISN'T what the documentation said it would do!
It said it would warn you IF IT DETECTED null pointer use.
That is no guarantee that it will be able to detect all
cases of null pointer use - particularly not at compile
time! It's not even any guarantee that it will ATTEMPT
to do so!

The only way to detect ALL cases of null pointer use given
the rest of C's semantics is to insert runtime checks, and
as a rule C doesn't DO runtime checks. (except if you
use assert() statements and put them BEFORE anything that
depends on the occurrence of the potential error they check
for).

If the intent had been to warn you UNLESS they could prove
that there was no null pointer use, the doc would have told
you that sometimes there was going to be a warning on good
code, or it would have warned you that it would slow down
your code with runtime checks.

Either way, it would NOT have said that it would make
optimizations based on the knowledge that arguments would
be non-null!  Any time the doc says "will make optimizations
based on" anything you give it, it means you better be
right about it or your code will crash!  That's ENTIRELY
different from "will insert runtime checks to make sure
you're right" or "promise to statically prove at compile
time that you're right" or even "warn you if we can't
statically prove at compile time that you're right."

You told them it would never happen.  They based optimizations
on the "knowledge" that it would never happen.  If you weren't
*sure* that it would never happen, then you should not have
made that promise.

				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/20151101/66def7da/attachment.sig>