<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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". That's a very different thing from having rational,
safe, predictable language semantics for operations on types - but
it was also a strength, and a simple way to describe what C would
do, deferring to machine semantics. I believe one place in C89/C90
where this is stated explicitly, as "do what the machine does", is
"-1 >> 1", as opposed to "-1 / 2". On most machines, this
program:</p>
<p><font face="Courier New, Courier, monospace">#include
<stdio.h><br>
<br>
int main()<br>
{<br>
printf("%d\n", -1 >> 1);<br>
printf("%d\n", -1 / 2);<br>
<br>
return 0;<br>
}<br>
</font></p>
<p>returns:</p>
<p>-1<br>
0<br>
</p>
<p>directly reflecting the underlying machine shift and divide
instructions - but if you made an appeal to rational integer type
semantics, you might decide for it to do something else.</p>
<p>Old C was one way. Modern C has gone another way, good tools and
rational semantics for safer and/or higher performance code, or
some balance between those and other goals. Old C just did what
the machine did, and was a high leverage tool - but you had to
understand your machine.<br>
</p>
<div class="moz-cite-prefix">On 08/15/2025 11:02 AM, Nevin Liber
wrote:<br>
</div>
<blockquote
cite="mid:CAGg_6+OZOV0+yNm-T0pR3zqkhxOuhZAbY_B5hWg5JVcnXaV5hA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr">On Fri, Aug 15, 2025 at 12:32 PM Luther Johnson
<<a moz-do-not-send="true"
href="mailto:luther.johnson@makerlisp.com">luther.johnson@makerlisp.com</a>>
wrote:<br>
</div>
<div class="gmail_quote gmail_quote_container">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">My
belief is that this was done so compilers could employ
optimizations <br>
that did not have to consider or maintain
implementation-specific <br>
behavior when integers would wrap. I don't agree with this,
I think 2's <br>
complement behavior on integers as an
implementation-specific behavior <br>
can be well-specified, and well-understood, machine by
machine, but I <br>
think this is one of the places where compilers and
benchmarks conspire <br>
to subvert the obvious and change the language to
"language-legally" <br>
allow optimizations that can break the used-to-be-expected
2's <br>
complement implementation-specific behavior.<br>
</blockquote>
<div><br>
</div>
<div>It isn't just about optimizations.</div>
<div><br>
</div>
<div>Unsigned math in C is well defined here. The problem is
that its wrapping behavior is almost (but not) always a
bug. Because of that, for instance, one cannot write a
no-false-positive sanitizer to catch this because it cannot
tell the difference between an accidental bug and a
deliberate use. This is a well-defined case with a very
reasonable definition which most of the time leads to bugs.</div>
<div><br>
</div>
<div>There are times folks want the wrapping behavior. There
are times folks want saturating behavior. There are times
folks want such code to error out. There are times folks
want the optimizing behavior because their code doesn't go
anywhere near wrapping.</div>
<div><br>
</div>
<div>Ultimately, one needs different functions for the
different behaviors, but if you only have one spelling for
that operation, you can only get one behavior. A given type
has to pick one of the above behaviors for a given spelling
of an operation.</div>
<div><br>
</div>
<div>You can, of course, disagree with what C picked here
(many do), but it is unlikely to change in the future.</div>
<div><br>
</div>
<div>Not that it hasn't been tried. In 2018 there was a
proposal for C++ <a moz-do-not-send="true"
href="https://wg21.link/P0907R0">P0907R0 Signed Integers
are Two's Complement</a>, and if you look at the next
revision of that paper <a moz-do-not-send="true"
href="https://wg21.link/P0907R1">P0907R1</a>, there was no
consensus for the wrapping behavior. Quoting the paper:</div>
<div>
<ul>
<li>Performance concerns, whereby defining the behavior
prevents optimizers from assuming that overflow never
occurs;<br>
</li>
<li>Implementation leeway for tools such as sanitizers;<br>
</li>
<li>Data from Google suggesting that over 90% of all
overflow is a bug, and defining wrapping behavior would
not have solved the bug.<br>
</li>
</ul>
</div>
<div>Fun fact: in C++ <font face="monospace">std::atomic<int></font>
does wrap, so you can actually get the behavior you want. I
haven't looked to see if that is also true using C's <font
face="monospace">_Atomic</font> type qualifier.</div>
<div><br>
</div>
<div>Full disclosure: I am on the WG21 (C++) Committee and am
starting to participate on the WG14 (C) Committee.</div>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div> Nevin ":-)" Liber <mailto:<a
moz-do-not-send="true"
href="mailto:nevin@eviloverlord.com" target="_blank">nevin@eviloverlord.com</a>>
+1-847-691-1404</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>