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

[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.