[Kranar]

The difference is that hardware will treat addition in a predictable and consistent manner, but C and C++ will not. In C and C++, if you overflow two signed integers, the behavior of your entire program is undefined, not simply the result of the addition.

That's the difference between something being safe and local but perhaps it's unexpected because you lack the knowledge about how it works, and something being unsafe because there is absolutely no way to know what will happen and the consequences can be global.

[arcticbull]

> The difference is that hardware will treat addition in a predictable and consistent manner, but C and C++ will not. In C and C++, if you overflow two signed integers, the behavior of your entire program is undefined, not simply the result of the addition.

On the same hardware, yes, but the same C or C++ program may behave differently on different hardware specifically because the C abstract machine doesn't define what's supposed to happen. This leaves it up to (to your point) the compiler or the hardware what happens in, e.g., an overflow condition.

If you're planning on running the program on more than one CPU revision then I'd argue it introduces a similar level of risk, although one that's probably less frequently realised.

[Kranar]

Leaving the behavior up to the compiler (or hardware) is not undefined behavior, that is unspecified behavior or implementation defined behavior.

Undefined behavior really does mean that the program does not have valid semantics. There is no proper interpretation of how the program is to behave if signed overflow happens. It's not simply that the interpretation of the program is beyond the language and left to the hardware or the operating system, it's that the program's behavior is undefined.

[arcticbull]

Gotcha, thanks for the clarification.