From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id EDFBE3858D1E for ; Fri, 30 Dec 2022 13:28:10 +0000 (GMT) Received: from [172.17.203.2] (port=41285 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1pBFQe-008xmM-8e; Fri, 30 Dec 2022 13:28:08 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.94.2) (envelope-from ) id 1pBFQd-0000lP-TY; Fri, 30 Dec 2022 14:28:07 +0100 From: Florian Weimer To: Andreas Schwab Cc: Zack Weinberg via Libc-alpha , Carlos O'Donell , Zack Weinberg Subject: Re: =?utf-8?Q?=E2=80=9CUndefined_behavior=E2=80=9D?= considered harmful (was Re: Bug 29863 - Segmentation fault in =?utf-8?Q?memcmp-sse2=2ES=E2=80=A6=29?= References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> <0b2901d90f26$f82b4720$e881d560$@yottadb.com> <38450ca5-599d-4e5d-b2db-be01856680cb@app.fastmail.com> <736bb5b6-f9d5-b541-f983-1e5026aaacfa@redhat.com> <87y1qp97j4.fsf@igel.home> Date: Fri, 30 Dec 2022 14:28:07 +0100 In-Reply-To: <87y1qp97j4.fsf@igel.home> (Andreas Schwab's message of "Thu, 29 Dec 2022 23:20:15 +0100") Message-ID: <87bknl3tso.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Andreas Schwab: > On Dez 29 2022, Zack Weinberg via Libc-alpha wrote: > >> 1. The C standard uses =E2=80=9Cundefined behavior=E2=80=9D far more lib= erally than it >> ought to. In many cases of existing UB the committee could define >> the behavior (possibly as implementation-defined or unspecified) >> without any actual negative consequences. It seems the committee >> *is* moving in this direction as of C2x, for instance by dropping >> the allowances for non-twos-complement signed arithmetic, but they >> could and should go a lot farther down that road. > > That's not removing an undefined behavior, it's removing an > implementation choice. Right, arithmetic is still not twos-complement, it's only about representation. Same with C++. (I associate twos-complement signed *arithmetic* with the obvious (unsigned) overflow behavior.)