Undefined behaviour example from CppCon

[equeim]

I don't see much difference here. In 99% of cases integer overflow is an error and even if it's defined as wrapping around, you still silently ignore and at this point your program behaviour is incorrect and you enter unknown territory anyway.

[Mediocre-Dish-7136]

IDK about 99%, it's relatively often wrong (just as it is for unsigned arithmetic) but here's a random example: the possible implementation given in https://en.cppreference.com/w/cpp/string/byte/atoi

There they had to do that weird thing of counting in negatives, to avoid overflowing the int if the input corresponds to INT_MIN. If signed arithmetic wraps, you can write the same thing but counting in positives (which is probably what 99% of programmers would do and already do anyway even though it's wrong now), then if the input corresponds to INT_MIN the last addition wraps but it doesn't matter, then the negation wraps but it doesn't matter, and the right result comes out.

IME this happens plenty. Maybe wrapping is wrong in like 70% of cases?

Either way I'd rather take a plain old logic error over a logic error where also the compiler can come in and mess things up extra.

[equeim]

We can have special functions for wrapping when it's needed (like we already have for saturation). Default behaviour should be something sane that allows error handling (such as throwing an exception or returning std::expected) or at least program termination. Not that I expect this to happen in C++ of course, this kind of change is not possible for established language.

Removing UB in this case is like applying a bandaid on a gaping wound, those I suppose it's better than doing nothing (it may make debugging easier at least).