[Cryptography] GCC bug 30475 (was Re: bounded pointers in C)

[wish at dumain.com]

Thus Spake Arnold Reinhold <agr at me.com>:
> Why would you want the compiler to silently remove that code? If it wasn't =
> an overflow check, maybe you made a typo--when you wrote that line you had =
> something in mind.  Wouldn't it be better for the compiler to flag that sta=
> tement so you could review it and either correct it or remove if from your =
> source file? Why would you want a nonsense statement to remain in your prog=
> ram? =

Because one wants an optimising compiler that replaces expressions that evaluate
to constants with those constants and eliminates dead code.  What expressions
evaluate to might be different on different platforms so the code may be portable
rather than nonsense.  

You do have a real choice as to what compiler to use and with which optimisation
and warning flags.  

Spotting this sort of thing isn't the job of the compiler but for lint 
and it's descendants.  

> > Perhaps a language that requires arcane techniques to write safe code
> > should not be used for anything security sensitive.
> 
> That horse has left the barn long ago. Thousands of security sensitive prog=
> rams written in C are in use today. And programmers don't often have the lu=
> xury of deciding what language to use. Often security is only a small part =
> of a larger project and the choice of which language to use for a project h=
> as been decided for other reasons. Isn't it more reasonable to expect the d=
> evelopers of C to respond to the safety needs of their users and the public?

If we're talking about horses that have left barns I think it is too late
to make 'C' into a language safe against common programming mistakes.
You would need to break a lot of well defined features that all those
programs depend on.  Given that 'C' can't be made safe and still be 'C'
why cripple the optimiser trying?  I further suspect the popularity of 'C'
is, at least in part due to it not trying to protect you from yourself.


> Well, to begin with Bug 30475 was about an assert statement and these are p=
> retty much always safety checks. I realize that assert is a macro, but in p=
> rinciple there is no reason the compiler can't be aware of this. But not al=
> l safety checks are written as asserts. A program abort may not be the safe=

Having assert make the compiler look for undefined behavior is a good idea.

>  response to an error. So yes, I am saying  that compilers should never sil=
> ently optimize undefined behavior. An optimizer is supposed to generate cod=
> e that produces the same output as the original program, but more efficient=

What original program?  We have the source code and a compiler that
can be tuned to trade off various things such as memory usage, compile
time and speed of execution of the code output.  It chooses an object
code representation that best suits the requirements and conforms to
the standard.  There is no reference implementation against which its 
behavior can be compared.

> ly. If a behavior is undefined, how can the optimizer conclude that the out=
> put will be the same? I would think undefined behavior is the last thing I =
> would want an optimizer to touch. =

I think in this context undefined means undefined by the standard and
therefore available for the implementation to define.  I doubt there is
any way for an implementation to avoid defining 'undefined behavior' as
it has to do something when confronted by it.  The optimising compiler
is the implementation in this case so it gets to define what the output
should be.

Imagine an architecture  where the compiler that does its 32 bit integer
maths in 64 bit registers and only worries about whether the result fits
into a 32 bit int when assigning the result to a variable or passing it
as a parameter.  Your pet assert would fail with such an implementation
without an optimiser in sight.  I believe such an implementation would
still be correct according to the standard as it should produce the
same result in all cases where the output is not left as undefined by
the standard.

William