[caspper69]

Not all UB falls into this category. A lot of UB, such as your signed integer addition example, is dependent upon the behavior of the underlying hardware. Certain archs may throw an exception on signed integer overflow, or exhibit otherwise inconsistent behavior, for example. The standard is the standard, of course, but not all implementations inherit the UB of the standard.

[bhk]

Whether or not something is "undefined behavior" has nothing to do with the hardware. The C specification says what is specified, what is "unspecified", what is "implementation defined", and what is "undefined".

If something is "undefined" according to C, you can't rely on what the hardware does, because the hardware might not even get a chance to do anything. The compiler may completely elide sections of your program -- and they do in practice (for example, bounds checks).

Actually, hardware always does something reasonable for add instructions (throw exception or overflow or saturate). It's additions in C that can have unreasonable results.

[Gibbon1]

> A lot of UB, such as your signed integer addition example, is dependent upon the behavior of the underlying hardware.

That problem is you can no longer depend on that because the compiler writers have decided they can do anything during AST optimization when there is undefined behavior.

[qw3rty01]

That's because...they can. Because the behavior of the statement is undefined.

[perl4ever]

“Those who can make you believe absurdities, can make you commit atrocities.” -Voltaire

Who knew he was talking about C compilers??