Re: Small and unlikely overflow hazard in bms_next_member()

On Thu, 2 Apr 2026 at 17:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Assert(prevbit <= a->nwords * BITS_PER_BITMAPWORD);

> but if the bitmapset were large enough to accommodate INT_MAX
> as a member then a->nwords * BITS_PER_BITMAPWORD must overflow.

I missed that one. That's annoying. Even "prevbit = a->nwords *
BITS_PER_BITMAPWORD - 1;" is undefined if it wraps due to the signed
maths.

> I don't think we should add cycles here for this purpose.

I'm not keen on slowing things down for this either. I did do some
experiments in [1] that sees fewer instructions from using 64-bit
maths. I might go off and see if there are any wins there that also
give us the INT_MAX fix. It's not great effort to reward ratio
though...

David

[1] https://godbolt.org/z/Eh1vzssq7