From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28576 invoked from network); 4 Jun 2022 18:16:53 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Jun 2022 18:16:53 -0000 Received: (qmail 30631 invoked by uid 550); 4 Jun 2022 18:16:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30590 invoked from network); 4 Jun 2022 18:16:50 -0000 Date: Sat, 4 Jun 2022 14:16:36 -0400 From: Rich Felker To: Pascal Cuoq Cc: "musl@lists.openwall.com" Message-ID: <20220604181636.GB7074@brightrain.aerifal.cx> References: <20220604172550.uf7vboamzar4etk3@gen2.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] fix undefined behavior from large shifts On Sat, Jun 04, 2022 at 06:04:15PM +0000, Pascal Cuoq wrote: > > > On 4 Jun 2022, at 19:26, NRK wrote: > > > > + uint32_t nw = (uint32_t)n[0]<<24 | (uint32_t)n[1]<<16 | n[2]<<8; > > + uint32_t hw = (uint32_t)h[0]<<24 | (uint32_t)h[1]<<16 | h[2]<<8; > > If it were a goal to support 16-bit ints in musl, then your patch > would still have UB by shifting a 1 into the sign bit with > {h,n}[2]<<8, which in C is a form of signed arithmetic overflow (the > C++ standard makes a special case for this situation but the C > standard doesn't). > > However, I do not think it is a goal to support narrower that 32-bit > ints in musl, and the original code is free of UB in these > conditions. Indeed, musl code assumes int is at least 32-bit since it assumes the class of ABIs it supports. It's arguable that the source files that are "pure library" code that don't have anything to do with being part of a unified implementation code base could/should be written with even fewer assumptions, but there's a lot of subtle pain in environments where default promotions don't do what you expect, and I don't think it's a good use of time to try to maintain that in a good state. If you're really targeting some tiny 8bit microcontroller or whatever, you don't want the code that's in musl; you want either even more naive implementations of these functions for minimal code size, or hand written asm. Rich