[cfe-dev] Traps for signed arithmetic overflow

[Segher Boessenkool via cfe-dev]

On Sat, Nov 24, 2018 at 09:33:20PM +0800, Liu Hao wrote:
> 在 2018/11/24 5:36, Marc Glisse 写道:
> > On Fri, 23 Nov 2018, Helmut Eller wrote:
> >> On Fri, Nov 23 2018, Marc Glisse wrote:
> >>> On Fri, 23 Nov 2018, Helmut Eller wrote:
> >>>> when compiling this example with gcc -O2 -ftrapv:
> >>>> [...]
> >>> Try with "-fsanitize=undefined
> >>> -fsanitize-undefined-trap-on-error". -ftrapv is quite broken and not
> >>> really maintained. I think fixing it would mean making it an alias for
> >>> the sanitizer version.
> >>
> >> Thanks for the quick reply.  That does indeed produce exactly the code I
> >> want.
> >>
> >> It doesn't seem so detect overflow for short or char types, though:
> > 
> > That's because there is no overflow. Read about integer promotion.
> 
> I think I had better say something about this.
> 
> You are right; there is no overflow. But who needs such apparently
> deficient (if not incomplete at all) behavior? People could start
> arguing that integer promotion is mandated by the C standard and is what
> 'portable' code might rely on. Yes you are right, totally right about a
> _very_ poor excuse: The so-called 'portable' code should not rely on the `int`
> -> `short` conversion either, which is implementation-defined and not so
> portable after all. It is a shame for C to have integer promotion. It is
> a flaw for UBSan to discriminate overflows on `short`.

-fsanitize=undefined instruments undefined behaviour.  This isn't undefined
behaviour.  Also, both -fsanitize=signed-integer-overflow and -ftrapv are
documented to only do things for addition, subtraction, and multiplication
(not conversion).

If you want a warning for implementation-defined behaviour, sure, not many
people will oppose that (it will warn all of the time, making it not very
useful, but hey).  Still, it should be a separate option.  Implementation-
defined behaviour is not undefined, after all.


Segher