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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,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 [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 369D625A75 for ; Fri, 15 Aug 2025 19:37:12 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 1F9CE43BDA; Sat, 16 Aug 2025 03:37:08 +1000 (AEST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by minnie.tuhs.org (Postfix) with ESMTPS id CD7B643BAD for ; Sat, 16 Aug 2025 03:37:02 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=makerlisp.com; s=s1-ionos; t=1755279422; x=1755884222; i=luther.johnson@makerlisp.com; bh=0rlYy1Q35Y8zrp89psB6dNKaemmQp38zV3yIH715wH4=; h=X-UI-Sender-Class:Subject:To:References:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=GjqRqy+RMvzyewCX6WAU+yzcON+O1dMS5kgwWlFU9x186dNAnKP2a1aT6Q8c7XkH ikkmw1cDFwRYTDcnpD7MbS+3rlqCH2NR4wOr/bhW70nwBp5Bn2UnQmBWRYLi3dvMu SfhkYaznGwe2i9YFQVGb/zLWwz9ib3ZGDjdh+CzUb/yoChSPjPwbazNHuEb9wKOyW mHZfKNJBLdRquLprFWvlOGZ0JmjuMoGpKWkf/vcepkot853f85FeOs7kAOcWxsZGx PjElcs8LeqQrvNBlf5yZSePEkQqlOpMV+A3ahjAUoOma4+y4CJwg28DMi//FtumZl 84FJOvvayyZFdxiBlw== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from mlhivps ([74.50.126.128]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1Mys3C-1uQTj53psA-017Auc for ; Fri, 15 Aug 2025 19:37:02 +0200 Received: from [192.168.234.130] (unknown [172.56.176.94]) by mlhivps (Postfix) with ESMTPSA id 21DA0480169 for ; Fri, 15 Aug 2025 17:37:01 +0000 (UTC) To: tuhs@tuhs.org References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> From: Luther Johnson Message-ID: <2e3d71c9-167e-b5d7-0d68-516248d91cf3@makerlisp.com> Date: Fri, 15 Aug 2025 10:36:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:/hOkBHh84geAHJ7kFae/QEKtIa3JivI45LOCbkfHx0z3ZOh4zza dDcFY9tNTDqISBpRBHJHKllY6fnAyOOd/anfn9T0HUYTk2EOtlaHxxTpfrP5cKiPuTFsv6z F+1875HRPj2CFyYD4X78vB626OSfdPA7Ojp0frDwrnY4ea2pLSzbOU+aedJwO3wJFt6o4zm WUNQ1zOh4/Rd7hXzNWLQw== UI-OutboundReport: notjunk:1;M01:P0:yDyBd6NqRwU=;lYg42jwQh4bPa3trHaf8yikg4W7 1QxrfpTYxvUfLLW1zIGS5K3i6FQhP7F5Z8p/TpV1tSbog7qy3AyEFGCOG3ajqKa2MXpI9YDrW AsrQyl4JGQQkDIOTdXaHKCDUuJYGZYxpvGvbRM0vWa//rLZQGs9kf70nB6EJd6oLjX+Gae1Ew R5ymInWexi3/Dq2WNWhWdygjJudxO23qNBRs88NIS60y1dUyEl03JBI7+eN1iYAs0RipbdnZd LzGbFYvrYMnOZdSs1R7zKwT45Bd/l0dGkauVTHH4JBfZr7h9YfdArkde2CE7OD8gblmSnP0hv XCeZuzzQwZ+qwj/fJcf1UfonI96TYyCMcJi1yz/QwV0AADMrUQ+x52mMC++S6R+Y+3DR+ILcz My06pTl4+bcqrxJ+LRFOD4YhledTnDbeId5tIrEX9Z4fItWLHtAu2gjz+nVE9Qii+EDuZZUwm 8YqWkEVaM3tAGP4hfFk1r1kxExA5Wt1PI2S6ojjiHWBdvjy14Xu0EG0OGs9Tye0mC7kukr975 Cp224DW56xpbAFCPdsWrNS/ohqercwmfLQh8QQ6Re+10VcGCoNIPnYYHR0ymnVa81X46AqkYQ 2qWCpxJ3Ee2uBD4b2Vdzx8qGNPYIKm+zqKhA7V2ncAGr/OSc/DBbbtUsioS/oT8e/93ucFo5H C0JRTEMXd9SabLAAsQqLQyi5OM72s+9r9iG47ig0c+iTP/y4zwgxE1qnW/LEyiTI05phuiNM8 jeNj/QWsu/n/qChYoTGJmMYr/NY+YsmsasnM0OAK/BoxD2/6JiBedLlh3wwx8rrbPCseoxkhZ ulD9raftFg08LR8XvTv/3mRNGt/wpUYQ2gwOFJgXI+rX6G3OlVgruFHmHPaMJcXEpJPulqEGG q+UG7HALNo6i6gYwFV+vor5+QkcD716ZKGK/n0DZPNWNW+DxkawJ76iF5qf+QybTZUhAEua28 lsONYOCWaK5Z1NRABS1mg9KwJk19tJEm6AFKn4BBZUiTKgEhfUUFmQU+vaZxaRjT/focg7D2m gF02w3aa/jqaH1KGPsdpqfy/8M50yaBN5wF1OuNoiSu6eUjqHh0i/dgsjjrcsX9cr4KLBy8k/ U1IFmt2kQVK0c3Fo1DrfvNyRNKtnoE+hWjkf8NBMtjzGFc1ZoRykMetdiOCRwi0tR6rlwIXk7 DSOQaY4Cyz+UgDFJsQanRVaADkUKuhzUQ+lO2oBhFwpothcD2OpaumA0K+J/FwSgN9esMmW4x Sln5mWFiOaPFfYTdxehxBL0dzpivXT1tAM1F2uOHSu71lqm1mgiI+cPqFOw2bCttnnG30JtRs 7sjFoBzQjootBPs4DrPrIHqwaas9IjB0QUV8eFO3e/oV4k5OpzumEqr2HwtXrzR29pj0s+R1f iAKWCuoaoMdQokA3h07UiPL8pc7a5xbCpxEc5/FwKN5BEguN1muJRg8EelY68POBLkNs8ivjG l3c0P/xio/lfR8YljqniWg45xcyCCZjKd3WU/sP+mmj5D1cWTv/gm17gBvuER2RpXw6aftbNt FxofcfDT262leJcfmPVuSzJjIh88WpUTWjElle+SmPq5YD3m5ABXb84dTSp6T2oDTwNylwbAi W3RGJwvIs9Et251B1piskLTmq2UDIzf Message-ID-Hash: VZJIUAVBDZZZZLN6HZEF26TKXP5KD5SA X-Message-ID-Hash: VZJIUAVBDZZZZLN6HZEF26TKXP5KD5SA X-MailFrom: luther.johnson@makerlisp.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 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: Or one's complement on those machines, but the idea was that this case=20 is out of bounds, so you don't have to worry if munging some computation= =20 by substituting or rearranging expressions would change it, whatever the= =20 machine-specific behavior was. On 08/15/2025 10:31 AM, Luther Johnson wrote: > My belief is that this was done so compilers could employ=20 > optimizations that did not have to consider or maintain=20 > implementation-specific behavior when integers would wrap. I don't=20 > agree with this, I think 2's complement behavior on integers as an=20 > implementation-specific behavior can be well-specified, and=20 > well-understood, machine by machine, but I think this is one of the=20 > places where compilers and benchmarks conspire to subvert the obvious=20 > and change the language to "language-legally" allow optimizations that= =20 > can break the used-to-be-expected 2's complement=20 > implementation-specific behavior. > > I'm sure many people will disagree, but I think this is part of the=20 > slippery slope of modern C, and part of how it stopped being more=20 > usefully, directly, tied to the machine underneath. > > On 08/15/2025 10:17 AM, Dan Cross wrote: >> [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. >> >