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

[Luther Johnson]

Relating this all to a Godel-ish classification of axiomatic systems, 
language definitions with undefined behavior may be perfectly 
consistent, but there is useful behavior that cannot be expressed in 
those languages, while languages with no undefined behavior but with 
lots of implementation-specific behavior can express much more, but with 
less consistency.

On 08/15/2025 02:04 PM, Douglas McIlroy wrote:
> Idle thought; There's been mention of 1's complement. If overflow is
> UB because of that possibility, maybe ==0 should be, too!
>
> Doug
>
> On Fri, Aug 15, 2025 at 2:44 PM John Levine <johnl at taugh.com> wrote:
>> It appears that Luther Johnson <luther.johnson at makerlisp.com> said:
>>> -=-=-=-=-=-
>>>
>>> I hear and understand what you're saying. I think what I'm trying to
>>> point out, is that in C, as it was originally implemented, in
>>> expressions "a + b", "a >> 1", "++a", C "does what the machine does".
>> We just had the same argument in comp.arch and came to largely the same
>> conclusion.  While overflow behavior on any particular machine may be
>> predictable, there's no consistency from one machine to another,
>> particularly back when there were still one's complement machines
>> where people compiled C code (some of the Univac mainframes.)
>>
>> It isn't all that predictable even on a single machine.  I know several
>> where overflow might or might not trap depending on a program-settable
>> status bit.
>>
>> R's,
>> John