From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 05DD83858CDA for ; Fri, 30 Dec 2022 20:38:17 +0000 (GMT) X-IronPort-AV: E=Sophos;i="5.96,288,1665475200"; d="scan'208";a="92122844" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 30 Dec 2022 12:38:15 -0800 IronPort-SDR: gTiL1O28D1chRjVJMC75Aj64gIf68m/LH7PQl0jKbVDfb5Ct/zkqAwRGDvPZFvQGC2Q3bXdzvK q5qXUSrIcxx5LUF11tqiPzb09SYOfPUc2hXksEuxIr7koicQZtQDFaCUk0QwIRXEHN4mGeIvyJ TL6/SlOtgcJnec4Q/b+Wju1F9lL9d4QO9ZjBoEyUJ+PgXOtisteE8WPYLY7uWDe48LonB7+hPR gI87RxiSmBzCBTvEZ31g6rwXudJt8qPb+zBE4pTGR14SjwTmxXxxtdZFHm1TxlYlim081CeXJf nxc= Date: Fri, 30 Dec 2022 20:38:11 +0000 From: Joseph Myers To: Alejandro Colomar CC: , GNU C Library Subject: Re: stdc_bit_ceil(3) and wrapping In-Reply-To: Message-ID: <8e45df-4b3e-e648-e14-b5d7ce15311f@codesourcery.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3109.2 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote: > I was wondering if there was any reason to make that UB in the standard, when > unsigned wrapping has always been well-defined, and this is a case that is > likely to be implemented with some operation that wraps around, right? I It's likely to be implemented by a shift, that might be by the number of bits in the argument in the overflow case, and shift by the width of the argument is undefined behavior; some architectures wrap the shift count modulo the width (do you actually want 1 or 0 as the result of stdc_bit_ceil?), some wrap the shift count modulo a larger value (e.g. treating 1 << 32 as 0 but 1 << 64 as 1) and for some architectures the result depends on the particular shift instruction used (meaning undefined behavior on the form of the result of an integer expression possibly comparing unequal to itself because the compiler duplicated the expression and then used different instructions to compute it in different places). > Would you consider either or both of being more generous in the GNU > implementation and guarantee wrap around, and/or suggest that the standard > guarantees the wrap around? The CD ballot has closed, and this doesn't appear to be one of the 338 comments raised on that ballot, and I don't really expect time at next month's meeting to deal with additional technical comments not on that list, when we have only 15 hours to deal with 338 comments. Once we have an issue tracking process for the C standard again (hopefully involving an issue tracker that the public can readily submit issues in), I'd suggest raising such concerns there (unless there's a CD2 ballot; technical comments are best avoided at a DIS ballot if possible). -- Joseph S. Myers joseph@codesourcery.com