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, URIBL_DBL_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 BCE5B25CE5 for ; Fri, 15 Aug 2025 20:44:21 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id E1C9943C02; Sat, 16 Aug 2025 04:44:15 +1000 (AEST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) by minnie.tuhs.org (Postfix) with ESMTPS id F2F4043C01 for ; Sat, 16 Aug 2025 04:44:10 +1000 (AEST) Received: (qmail 34547 invoked from network); 15 Aug 2025 18:44:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=86f1689f7ff9.k2508; t=1755283439; x=1755629039; bh=EPoIbLdklktd3P/sf1UBuBWzh+fRtym0V6YuxD8/E4M=; b=LIU7WjVuImnwqYOoOLO8XtQ/O+Ozt/KBTmAjLbtNNhzE17e6KOkeXkIVLrgnJKvJ9r+BZ+wqbBfs39qFLk6Udc/7GYAXS8BRr7y0VmuhV6qFVATHJCaED6Hqpn3dPzjMELMJ2qti25dLr7rxThTosjcZ/htM+N7WdpVfhKktmyXNJAo7MntIpAz1OD5xMH2e02LYpH6OPl6qxyaZxIhSsM4F1mpFvaFJD6f5KpV6818jV/SxXQI5/4xrCurf9YOv4dv76qNixEgoCweQjY8jQKqDj/8NAWa2fHmFoVtbiW5zqC+kGhOzrEzHCOAW8krk0f50eTEBK9FXSraRt39GPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=86f1689f7ff9.k2508; bh=EPoIbLdklktd3P/sf1UBuBWzh+fRtym0V6YuxD8/E4M=; b=xQiOiydMf3wac5LejmVWYbSR6edNo3VSF+u4pmPXEwnonERMpprAL8y9cIGBcYR1AZ+dxHE3ZiFnwndhFTiFcBgyw207n++u3SFWGx03HCHbLYqSVaKR0we2FYnJXC21g6Xw9QBKh1BeUivdcJA82rja/IkPqVAxcZyYj6udgC7SvVGHbTifwL+BGldHCoIdN8Ma5zkBNykVLC6bqkiuVsify1BVYNnvppIgO4ZOniZtdYTOrOoxRy0L+dZ+XxeQaHAiXHqRd6aV4r7rOintTcdA4h5XO5eBjTPq9hPhm06fiVMERZ7GVUO5v3g4q4ZDkk/ToAH/6y8toRnDC3XrOg== Received: from ary.qy ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA CHACHA20-POLY1305 AEAD) via TCP6; 15 Aug 2025 18:44:09 -0000 Received: by ary.qy (Postfix, from userid 501) id E438DD7D00B1; Fri, 15 Aug 2025 14:44:08 -0400 (EDT) Date: 15 Aug 2025 14:44:08 -0400 Message-Id: <20250815184408.E438DD7D00B1@ary.qy> From: "John Levine" To: tuhs@tuhs.org In-Reply-To: Organization: Taughannock Networks References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Message-ID-Hash: CRV5I32HFPBGFO2GWQNULO57YN27MGYE X-Message-ID-Hash: CRV5I32HFPBGFO2GWQNULO57YN27MGYE X-MailFrom: johnl@iecc.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: luther.johnson@makerlisp.com 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: It appears that Luther Johnson said: >-=-=-=-=-=- > >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". We just had the same argument in comp.arch and came to largely the same conclusion. While overflow behavior on any particular machine may be predictable, there's no consistency from one machine to another, particularly back when there were still one's complement machines where people compiled C code (some of the Univac mainframes.) It isn't all that predictable even on a single machine. I know several where overflow might or might not trap depending on a program-settable status bit. R's, John