[aragilar]

Wouldn't a faster and easier solution for existing code be to come up with a standard set of behaviours based on common architectures and make that a flag that can be switched on so expectations can be met (and call it "expected-C" or for the pun "ocean")?

[flohofwoe]

AFAIK the reason for signed overflow still being UB isn't any exotic hardware property but because it enables some specific optimizations. Whether those optimizations are worth the trouble is up for discussion I guess.

[simonask]

No, it used to be the case that there were architectures where signed integers were represented as 1s complement, so portable code could not rely on signed integer overflow wrapping around (there would either be 2 bit patterns representing zero, or sometimes the all-ones pattern had special meaning, like a trap).

Using this type of UB is a "relatively" new thing (GCC started doing it in the 00s, which broke a lot of stuff in the Linux world, IIRC).

It _is_ true that somebody did the research (can't find the source right now) and found that defining signed integer overflow as wrapping did indeed make some code run slower. I'm skeptical that it matters.

[flohofwoe]

That's why I wrote "still". AFAIK both C++ and C now expect integers to be in 2s complement and made unsigned overflow 'defined', but at the same time kept signed integer overflow as undefined behaviour.

[fanf2]

unsigned overflow was always defined

[flohofwoe]

Hmm true, now I wonder what the standard change that integers are expected to be in two's complement format even means in practice when the only important related UB (signed overflow) is still UB. Guess I'll need to read the original proposal again.