This particular undefined case is a really interesting one; it seems utterly non-obvious why it exists, until you remember one thing...
The most popular architecture today is 64-bit, with ABI specifying that the integer type is 32-bits wide.
So when faced with performing an operation on two 32-bit signed integers, on a 64-bit platform, you have to either:
1) perform the operation in 32-bit registers - if available - and even if available, usually far far far fewer in number thus massive performance & resource penalties to code
2) perform the operation in 64-bit registers, then add code to check the result, and if it would overflow in 32-bit, compute what the overflowed result would have looked like in a 32-bit register, and return that instead - again quite a performance hit
3) perform the operation in 64-bit registers, and just return the lower 32-bits, whatever that might be
The standard declined to pick a choice, which is why we have UB here.
(For unsigned integers, you can just truncate the result and it works every time, which is why the standard defines the result)
The most popular architecture today is 64-bit, with ABI specifying that the integer type is 32-bits wide.
So when faced with performing an operation on two 32-bit signed integers, on a 64-bit platform, you have to either:
1) perform the operation in 32-bit registers - if available - and even if available, usually far far far fewer in number thus massive performance & resource penalties to code
2) perform the operation in 64-bit registers, then add code to check the result, and if it would overflow in 32-bit, compute what the overflowed result would have looked like in a 32-bit register, and return that instead - again quite a performance hit
3) perform the operation in 64-bit registers, and just return the lower 32-bits, whatever that might be
The standard declined to pick a choice, which is why we have UB here.
(For unsigned integers, you can just truncate the result and it works every time, which is why the standard defines the result)