[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 4 Jun 2022 18:04:15 +0000
From: Pascal Cuoq <cuoq@...st-in-soft.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: [PATCH] fix undefined behavior from large shifts
> On 4 Jun 2022, at 19:26, NRK <nrk@...root.org> 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
