Re: Small and unlikely overflow hazard in bms_next_member() - Mailing list pgsql-hackers

From David Rowley
Subject Re: Small and unlikely overflow hazard in bms_next_member()
Date
Msg-id CAApHDvqO9v8w8qWap8t6CWxccwWYxXKQOeXqN+FjHx7fjgaE=w@mail.gmail.com
Whole thread
In response to Re: Small and unlikely overflow hazard in bms_next_member()  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Mon, 13 Apr 2026 at 01:17, David Rowley <dgrowleyml@gmail.com> wrote:
> Re-thinking this after a week's holiday, it seems fine to use an
> unsigned 32-bit int rather than a 64-bit int to fix this bug. I'd
> previously been uncertain if there were any guarantees in C to what
> (unsigned int) -1 would return, but going by [1] at 6.3.1.3, it says:
>
> "Otherwise, if the new type is unsigned, the value is converted by
> repeatedly adding or subtracting one more than the maximum value that
> can be represented in the new type until the value is in the range of
> the new type."
>
> So, it seems even on one's complement that -1 as an unsigned int will
> be UINT_MAX. When we add 1 to UINT_MAX, we're guaranteed to get 0, as
> it's unsigned maths and overflows are going to result in a value
> modulus the max value for the type.

I've pushed that version. No backpatch.

David



pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Use proc_exit() in WalRcvWaitForStartPosition
Next
From: Michael Paquier
Date:
Subject: Re: Non-compliant SASLprep implementation for ASCII characters