<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">below...</font></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Aug 15, 2025 at 10:18 AM Dan Cross <<a href="mailto:crossd@gmail.com">crossd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[Note: A few folks Cc'ed directly]<br>
<br><br>
<br>
Starting with the 1990 ANSI/ISO C standard, and continuing on to the<br>
present day, C has specified that signed integer overflow is<br>
"undefined behavior"; unsigned integer arithmetic is defined to be<br>
modular, and unsigned integer operations thus cannot meaningfully<br>
overflow, since they're always taken mod 2^b, where b is the number of<br>
bits in the datum (assuming unsigned int or larger, since type<br>
promotion of smaller things gets weird).<br>
<br>
But why is signed overflow UB? My belief has always been that signed<br>
integer overflow across various machines has non-deterministic<br>
behavior, in part because some machines would trap on overflow while others used non-2's-complement<br>
representations for signed integers and so the results could not be precisely<br>
defined: even if it did not trap, overflowing a 1's complement machine<br>
yielded a different _value_ than on 2's complement. And around the<br>
time of initial standardization, targeting those machines was still an<br>
important use case.  So while 2's complement with silent wrap-around<br>
was common, it could not be assumed, and once machines that generated<br>
traps on overflow were brought into the mix, it was safer to simply<br>
declare behavior on overflow undefined.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">We need someone like Peter Darnell, Plauger, and some of the original ANSI C weenies that had to argue this all through in those days, but I think you caught the core issues.</font></span><font color="#0000ff"> </font></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">This was just one of the many troublesome things that had to be worked through.  Until C89, the only ``official'' C was what Dennis shipped at any given time, and that was a bit ephemeral — particularly as the PCs and microprocessors C compiler implemented started to play fast and lose with the C syntax. </font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">The core task of the C89 was to do as little harm as possible.  My memory is that Dennis was pretty cool and rarely played his trump card (far pointers is one case I am aware that he told the 8086 people to pound sand) , but the compromise that the committee tended to use to kick the can down the road and get the standard out the door was to make things UB with the hopes that later versions could find a way to tighten things up.</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Truth is, other language specs had used that (like Fortran) , so it was not a bad idea. </font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">So, back to your question, I can not say what the actual cause if why there was a conflict WRT to </font><span style="font-family:Arial,Helvetica,sans-serif"> <font color="#0000ff">signed integer overflow, but I bet it was that, since so many compilers handled it in different ways, the committee did not have a way to make a formal standard that would work, and they never found one later.</font></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"><font color="#0000ff"><br></font></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"><font color="#0000ff">FWIW:   Remember, C89 tossed a lot of systems like the PDP-11 away with floating point.  It says, we are going to use IEEE 754.  So just because an old system used a format, did not guarantee it would be accepted.  </font></span></div></div></div></div>