[TUHS] C history question: why is signed integer overflow UB?

[Dan Cross <crossd@gmail.com>]

[Note: A few folks Cc'ed directly]

This is not exactly a Unix history question, but given the close
relationship between C's development and that of Unix, perhaps it is
both topical and someone may chime in with a definitive answer.

Starting with the 1990 ANSI/ISO C standard, and continuing on to the
present day, C has specified that signed integer overflow is
"undefined behavior"; unsigned integer arithmetic is defined to be
modular, and unsigned integer operations thus cannot meaningfully
overflow, since they're always taken mod 2^b, where b is the number of
bits in the datum (assuming unsigned int or larger, since type
promotion of smaller things gets weird).

But why is signed overflow UB? My belief has always been that signed
integer overflow across various machines has non-deterministic
behavior, in part because some machines would trap on overflow (e.g.,
Unisys 1100 series mainframes) while others used non-2's-complement
representations for signed integers (again, the Unisys 1100 series,
which used 1's complement), and so the results could not be precisely
defined: even if it did not trap, overflowing a 1's complement machine
yielded a different _value_ than on 2's complement. And around the
time of initial standardization, targeting those machines was still an
important use case.  So while 2's complement with silent wrap-around
was common, it could not be assumed, and once machines that generated
traps on overflow were brought into the mix, it was safer to simply
declare behavior on overflow undefined.

But is that actually the case?

Thanks in advance.

        - Dan C.