I'm starting to like Undefined Behaviour

....when I have warnings that will tell me about it.

So quite a few Rants have gone by about the behaviour of modern compilers around undefined behaviour.

The C standard says what happens when signed integers overflow is undefined.... so some compiler writers conclude that you have written the program so signed integer overflow cannot happen.

This is additional information that the optimizer may use.

Now I have been playing with gcc-7.2's -Wstrict-overflow=N

This warning is not enabled by default or by -Wall or -Wextra.

I hit a largish code base with this and this is the sort of thing it finds, in practice. ie. This isn't a theoretical debate about the merits and expectations of UB, this is a collection of practical examples in an industrial code base.

Examples have been extracted from body of code and simplified for readability reasons..

Message: assuming signed overflow does not occur when distributing negation across division

unsigned u = -i / 10;

Actually that is sort of cool. Especially on this tiny embedded target that doesn't have hardware implemented multiply and divide. So the compilers intent of translating that to

unsigned u = i / -10;

...is actually a fairly sane.

But wait? What is it whinging about?

Aha! The signed int gotcha.

-INTN_MIN is an overflow. It's undefined. So that simple obvious transformation is potentially behaviour changing.

Message: assuming signed overflow does not occur when simplifying division

if(remainder < 0)
{
     remainder = -(remainder);

     if(remainder*10 >  denominator*10/2)
    {

Again: If it ignores the possibility that remainder is INT_MIN to start with, it can assume remainder is positive in the next if.

But honestly, what do you as a programmer expect to happen in a case like that?

Message: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C2 -+ C1

if( i +1 > 10)

ie. It's transforming that to if( i > 9)

Again, that only makes sense if i+1 doesn't overflow.

Message: assuming signed overflow does not occur when simplifying ‘/’ or ‘%’ to ‘>>’ or ...

(i+1) / 2

Message: assuming signed overflow does not occur when simplifying conditional

These tend to be harder to spot and understand, so I haven't a clear simple example of them. If anyone cares enough I might do the work to extract and prove an example.

So how have I been cleaning up the warnings?

In some cases doing the transformation by hand, as it actually is better and more reliable code.

In some cases say, oh bugger, that's really a bug, the api of the function said it handled an int16_t input parameter, but we don't actually handle the INT16_MIN case correctly at all. So let me fix that.

The notion of a UB by itself sucks, UB optimizations with static warnings is actually surprisingly useful.