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
