From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_ZEN_BLOCKED_OPENDNS, URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 8C17826006 for ; Fri, 15 Aug 2025 20:03:24 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7B9BA43BE7; Sat, 16 Aug 2025 04:03:16 +1000 (AEST) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by minnie.tuhs.org (Postfix) with ESMTPS id E0B0D43BE3 for ; Sat, 16 Aug 2025 04:03:05 +1000 (AEST) Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-e931cdd710dso1880143276.3 for ; Fri, 15 Aug 2025 11:03:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755280985; x=1755885785; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R2ZIT0a0Nk+o7/kSEyu1rF52KQb/k+P/gxpWWEiHV8I=; b=c9ZQ8Q6iY7n6HX5IL9dvCrpCZMuCsilu23AhPlbXDSAc/UrKJkw7SPxJ98P0ZfoyLH 6JkOX1DBLtEkvr2EezqXS2QN3ON1CavBv/BGFrvD4JYPXUYHei2KPrDLwUHPwwypK3Vx oE5+c4ES6Us+Ha2p1Mx6NuN/gIw70ujFDprrLhxDjyba0EzYZbiR1gbY94tvPnWF+IF7 uV4bzf3Tz5pAOa7iGHuv3VFuDSxiVTXfe1boBuvThdArBBomTZydofR/PbeXKeC6/uTK NPovkkB5D8x3Y4emkAWuLl4UhPzwRsa187mDz3IHaCjo7ucfg8xysmFujV6W5TohGaZ9 FYcg== X-Gm-Message-State: AOJu0YzxrsIh3MgFbOFko5edHV8EtHZ3i0qbaOjG5sLUzzJy/1BqY30n 23lE8o7saBXC9a+T5z60oD5MFNfMgUbYzkzFaHj1i0xj+R7c9Nnh8GlJlu7Kbw== X-Gm-Gg: ASbGncuAETU7uNN1Mw04l01xcjhdSmx9FauwnmouL9f+gx3d2zarHVbIHTlnFXaJd+T a1C9BFJI5Nxe6FA7TkgQBWouvyqD1G7d95WjYx6I/M1P9gNJmQR442wrbOvnUbnnOZnatWkSCDn mE+YCzIgB464RDeCnkbQ5bWGJS8UyWDvt+iGRk3YEIWvn/0a6kdtpgIPMS4KU6kKjasf03sa5Jk TNWUDzU1QT/K3HeDRuqep8A0+cmG8M+PFp1Ve2BN5Mqg6Vzy68yg0hYe9gGEgYBzix0kiM/wBpf /gpxBs9AuZerfM3ejHG1NaGznjwQqg3t4uukmPFWH3VQ+Wynx66TQ0g9spX5/35ktd+0k5n9iBo rjZ0qkJsMOnj81WILZM5Th73eBBOSZWIdHbXx0Q4YkBkRP1J4tD64q6iDJkM6Q7I5dhm+8c8m5K paAA== X-Google-Smtp-Source: AGHT+IGPEx1sTDEdkZLDMrTdfLQ8Z+LggakuDLN/gyJ374dWI9jhKk5y1K4MTk/fkyz+VwLBzaqdtg== X-Received: by 2002:a05:6902:4a81:b0:e93:3d1c:297 with SMTP id 3f1490d57ef6-e933d1c191cmr663663276.39.1755280984118; Fri, 15 Aug 2025 11:03:04 -0700 (PDT) Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com. [209.85.219.177]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e933b1c04b9sm281891276.33.2025.08.15.11.03.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Aug 2025 11:03:03 -0700 (PDT) Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e931cc4c9e4so2234130276.2 for ; Fri, 15 Aug 2025 11:03:03 -0700 (PDT) X-Received: by 2002:a05:6902:2b08:b0:e93:2cea:b3f6 with SMTP id 3f1490d57ef6-e93325080abmr3736780276.43.1755280983461; Fri, 15 Aug 2025 11:03:03 -0700 (PDT) MIME-Version: 1.0 References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> In-Reply-To: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> From: Nevin Liber Date: Fri, 15 Aug 2025 13:02:26 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXxneUAr0b5Y5o5pvJX20QEwg8d78vl41Fe5aX2hcH0k10baFiylkksTOPk Message-ID: To: Luther Johnson Content-Type: multipart/alternative; boundary="0000000000008015e4063c6b331f" Message-ID-Hash: 6D6TFANWVBUHOTJYMXA5ZRA46Q6ZJR22 X-Message-ID-Hash: 6D6TFANWVBUHOTJYMXA5ZRA46Q6ZJR22 X-MailFrom: nliber@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: C history question: why is signed integer overflow UB? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008015e4063c6b331f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 15, 2025 at 12:32=E2=80=AFPM Luther Johnson < luther.johnson@makerlisp.com> wrote: > My belief is that this was done so compilers could employ optimizations > that did not have to consider or maintain implementation-specific > behavior when integers would wrap. I don't agree with this, I think 2's > complement behavior on integers as an implementation-specific behavior > can be well-specified, and well-understood, machine by machine, but I > think this is one of the places where compilers and benchmarks conspire > to subvert the obvious and change the language to "language-legally" > allow optimizations that can break the used-to-be-expected 2's > complement implementation-specific behavior. > It isn't just about optimizations. 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. 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. 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. You can, of course, disagree with what C picked here (many do), but it is unlikely to change in the future. Not that it hasn't been tried. In 2018 there was a proposal for C++ P0907R= 0 Signed Integers are Two's Complement , and if you look at the next revision of that paper P0907R1 , there was no consensus for the wrapping behavior. Quoting the paper: - Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs; - Implementation leeway for tools such as sanitizers; - Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug. Fun fact: in C++ std::atomic 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 _Atomic type qualifier. Full disclosure: I am on the WG21 (C++) Committee and am starting to participate on the WG14 (C) Committee. --=20 Nevin ":-)" Liber +1-847-691-1404 --0000000000008015e4063c6b331f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 15, 2025 at 12:32=E2=80=AFPM = Luther Johnson <luther.j= ohnson@makerlisp.com> wrote:
My belief is that this was done so comp= ilers could employ optimizations
that did not have to consider or maintain implementation-specific
behavior when integers would wrap. I don't agree with this, I think 2&#= 39;s
complement behavior on integers as an implementation-specific behavior
can be well-specified, and well-understood, machine by machine, but I
think this is one of the places where compilers and benchmarks conspire to subvert the obvious and change the language to "language-legally&qu= ot;
allow optimizations that can break the used-to-be-expected 2's
complement implementation-specific behavior.

It isn't just about optimizations.

Unsig= ned math in C is well defined here.=C2=A0 The problem is that its wrapping = behavior is almost (but not) always a bug.=C2=A0 Because of that, for insta= nce, one cannot write a no-false-positive sanitizer to catch this because i= t cannot tell the difference between an accidental bug and a deliberate use= .=C2=A0 This is a well-defined case with a very reasonable definition which= most of the time leads to bugs.

There are times f= olks want the wrapping behavior.=C2=A0 There are times folks want saturatin= g behavior.=C2=A0 There are times folks want such code to error out.=C2=A0 = There are times folks want the optimizing behavior because their code doesn= 't go anywhere near wrapping.

Ultimately, one = needs different functions for the different behaviors,=C2=A0but if you only= have one spelling for that operation, you can only get one behavior.=C2=A0= A given type has to pick one of the above behaviors for a given spelling o= f an operation.

You can, of course, disagree with = what C picked here (many do), but it is unlikely to change in the future.

Not that it hasn't been tried.=C2=A0 In 2018 th= ere was a proposal for C++ P0907R0 Si= gned Integers are Two's Complement, and if you look at the next rev= ision of that paper P0907R1, ther= e was no consensus for the wrapping behavior.=C2=A0 Quoting the paper:
  • Performance concerns, whereby defining the behavior prevents = optimizers from assuming that overflow never occurs;
  • Implementa= tion leeway for tools such as sanitizers;
  • Data from Google sugg= esting that over 90% of all overflow is a bug, and defining wrapping behavi= or would not have solved the bug.
Fun fact: =C2=A0i= n C++ std::atomic<int> does wrap, so = you can actually get the behavior you want.=C2=A0 I haven't looked to s= ee if that is also true using C's _Atomic type qualifier.

Full disclosure: =C2=A0I am on = the WG21 (C++) Committee and am starting to participate on the WG14 (C) Com= mittee.
--
=
=C2=A0Nevin ":-)" Lib= er=C2=A0 <mailto:nevin@eviloverlord.com> =C2=A0+1-847-691-1404
=
--0000000000008015e4063c6b331f--