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=2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_SBL_CSS, RCVD_IN_ZEN_BLOCKED_OPENDNS,URIBL_DBL_BLOCKED_OPENDNS, URIBL_ZEN_BLOCKED_OPENDNS autolearn=no 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 D58BF25468 for ; Fri, 15 Aug 2025 19:32:13 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 52CF043BD3; Sat, 16 Aug 2025 03:32:07 +1000 (AEST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by minnie.tuhs.org (Postfix) with ESMTPS id 1C02443BC1 for ; Sat, 16 Aug 2025 03:32:02 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=makerlisp.com; s=s1-ionos; t=1755279121; x=1755883921; i=luther.johnson@makerlisp.com; bh=rQKDqPb51FlfVRAPjDIQm8EqFCCNaMn3CuRFIewMsDY=; 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=Vuf19ZVqBu1kFz7VcqZqphRIVQ0SuWP9kc0Dey3HAdYFGlKAuy25RHVgq3hsj0K1 F8EEwEqeWuR2zSuD9i8HoUrCOZ52TDdrc3NLvR1Ao16lrdjxxDLo3BpymX5Ped9Ia xH+M0bHz19Et6l3uJJHsvI7tNQUlV+014p25omCDMsbTUA/X0nuWXEyB5X42LUuJW GqRBiDZ5Uq6VQ/maS8O1n+c618n4Lc7dWAqlPghdmNuRY++1dvDB5oLB7p2vFlZ6Q sgLwk/bWAzSmPAnXYdbrR+YWLPcGXg0aLqLk8+mLywdx2qYtZhJDOw6Ms23ud3qOZ 1YNjHweH34kSmKQ4gg== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from mlhivps ([74.50.126.128]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lt0Wa-1ubRko3UhW-01886H for ; Fri, 15 Aug 2025 19:32:00 +0200 Received: from [192.168.234.130] (unknown [172.56.176.94]) by mlhivps (Postfix) with ESMTPSA id B3845480169 for ; Fri, 15 Aug 2025 17:31:59 +0000 (UTC) To: tuhs@tuhs.org References: From: Luther Johnson Message-ID: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> Date: Fri, 15 Aug 2025 10:31:58 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:D+ZCR7R3OL1IriTZPamhauBmBlseYfhy6V8KUOtgfanxiUrbqF5 FNg/PC+AVka9KP/nbSvrIolerOCdzB0caKLqvdLijUZI+2Fv4o088kDp7gMGu6virA9zhFA jxPj5RePWGm+2L1f4XNsOapMsx8cRwf+0RtMPuZ72C+7/S2z1l84xg9cLutDTUmjAJ1w184 hWw45QqAvMYYdXxvmYqxQ== UI-OutboundReport: notjunk:1;M01:P0:i1IPK3Y0foM=;/hQPmeSlWfkB2qb438v7prZ6r9h gM1+9oXWEi4EmluKKbMS8MKnp1g3UVGiUWn/TW7y+ezepwNsz4eyuCWj3MrkPyv+jdeS8t/Es zqX20+5eHTq6xG43Jx3gYN/y/T24ck6hBkpwQ4/eAAWttO6SlxSWqOPpLbMreeZXuiulX2MgB +TwnhPCDW5UEG7y1YrS//3QhEyUNAWViKndG+usVxW88xqjjtNsarMLZaUFWSFFHk9IVXvFj0 WzCC1TO8jsldff+bvJD3zgQ6KwokvHzuffXSOy8zFF4YoTlcLpZZwCQ7eStKQV4a87lxEIAdf v9XxkNvhc8aCqIaYps46eb/7D55dw5/293HYgSvhIFzi3BoBAYakVZDkXvFLFq5JwZofYCPWy ZZKPAqoxHMCEJJyHOmkL9Cryp01wZ+jdElIu9KIC4/VrsJdVMUT1yEijXmgV5ssxGDlAYCfer eHWjPBJW+4b3hHWCibaCE+8G1Dd8MtCnHP1Esev2f0fVEGPuAlRA0/TSgaf9snLNmVavaX39a +eq7mbpT/DUzq8/giotOEg7TzkLxDq+VdjvZw7owzE2GdwhdtBZaD9+FjnfdGljRd8r6QLQaa uB1MiGK4K/bYpH4rQ3UGF1aCurVukP7FGwRYJmIugm/P+CSM2oxBy2OYc9pmG05CH4VB/JBBi sNVDDKfnCD9vFZISyscdyzKU4qLDbMuJzvU3gJuh1NdARSdhC9qZNeOZI/FaQT2NOXkQEwCCH zkYjlkfI5BWFn9GXsGBw92elJXKsfrxLAVgQuOqd6mjOhawC+7fUyHTMhNt3Ihy+DUg3L7Xay Li57cGmTbPLsycyG4EA4PiIZI77AExWEmiAcOhq6p/XyQ85XkEKydvXJ1ETErooTjQJrcGtud gJ4mVvgkbs/O3D+G53kh0zFGWj6XlJVAbDt27742/9uigwqeAwfAHVcW3Ax1xQn+iW3z/l98U QWrsjncpOZdCSFtoUpW0Iw8jvVL0P9I7wQgtZplTl70jIBrwIuoHLqYwRkYW8F8rHA5J5hymT btlFgDOGyKPrP12aWORl7e2bK/wMLqx9HuX2prR7uHqdCdS/tSB0DVlio061+eL/Dv54YyWwD LxxdCFRroHdrShs/ZKtUrXwFHnY3Jnxgf7Dpm8b9LUs2l4qK2fwaiNepahHnviL/fhH6DGdjD lvdA5ibWWVyXfcR3kuPcjgoFLDVwdKbtCQYEXfu4FBWoMqLI9cQfBC70ckEOrompcVCntPne7 uv6ZO2kCKgFXYqbKzvACis+A93szmFwq+Phasb1+T5Hm6TSoJaYk7OL7bp/TTdg9qMb788N/o N1I+qybJ5pY2B7023E17ZyoENLEc2iWFcGQgYMEqF7jiGKon1ZEjagMQM86w2Qo25c9oNOu8j wAmEVwmTenLEPZf7MpVLro5jLTmfB26LHWRv61+0L5E5M25zHcXybGvN0B1u5q9BbXvfS6X64 2Vu2q4QEU7V2xkdDLnhKiISbjUfng6yq4LaEkAc0KkM6CUkKBHAXOK24GJi4M1b0RFd74dR0r Zgng/Bj9nThpsjX8XtgOx87of4AZs1nqVuYCd+R+fGNMhimcGyu0qRt/UyLFn/oDCzaQyAUGY z4Wc/8T5PFiSwEog2R9+xUzXTrTTcGgAJkZes2wsngBhCen8k9ZZQ== Message-ID-Hash: W2SMCVKM7JNJAT2EYUA64OWBBE2OX5GP X-Message-ID-Hash: W2SMCVKM7JNJAT2EYUA64OWBBE2OX5GP 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: My belief is that this was done so compilers could employ optimizations=20 that did not have to consider or maintain implementation-specific=20 behavior when integers would wrap. I don't agree with this, I think 2's=20 complement behavior on integers as an implementation-specific behavior=20 can be well-specified, and well-understood, machine by machine, but I=20 think this is one of the places where compilers and benchmarks conspire=20 to subvert the obvious and change the language to "language-legally"=20 allow optimizations that can break the used-to-be-expected 2's=20 complement 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. >