Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 4 Jun 2022 18:04:15 +0000
From: Pascal Cuoq <>
To: "" <>
Subject: Re: [PATCH] fix undefined behavior from large shifts

> 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.

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.