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

[Stephan Neuhaus]

On 2014-04-25, 02:04, Bear wrote:
> 
> There are in fact conformant checks for signed overflow. 
> 
> For example, you can say 
> 
> if (MAXINT - al >= be) halt(2); // overflow check - not using assert()
>                                 // because we want this check in
>                                 // production code.
> ce = al + be;                   // addition guaranteed not to overflow.

And what do you do if al and be are of type ptrdiff_t, for example?  The
only thing I can think of would be something like

#include <stdint.h>

#if sizeof(ptrdiff_t) == 4
#  define PTRDIFF_T_MAX INT32_MAX
#elif sizeof(ptrdiff_t) == 8
#  define PTRDIFF_T_MAX INT64_MAX
#else
#  error Your ptrdiff_t has a weird size
#endif

I look at this code and am uneasy. It isn't portable, since int32_t and
int64_t are optional, and hence, so are the corresponding _MAX macros.
Is it guaranteed to work? I'm sure I could find out from reading the
standard, but it's not intuitive to me.

> What you can't do is check for overflow *AFTER* the operation that 
> might commit an overflow.  The instant you actually perform an 
> operation that might commit an overflow, the compiler is in fact 
> free to create any old evil code it wants including ignoring your 
> subsequent check.

If I read correctly, the compiler may even create evil code for stuff
that came textually before the overflowing computation, provided that
these preceding computations don't interfere with the overflow-producing
one and can thus be legitimately reordered.

And while I'm sure that you're technically correct, I still think that
the compiler writers should not read the standard as giving them license
to do literally anything (without a warning, which was the original
point of the bug report), but should instead try to preserve the
intention of the programmer (with a warning).

Fun,

Stephan