Horton
Menu

Re: Small and unlikely overflow hazard in bms_next_member()

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-02T22:12:15Z
Lists: pgsql-hackers 
On Thu, 2 Apr 2026 at 17:22, Tom Lane <tgl@sss.pgh.pa.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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix unlikely overflow bug in bms_next_member()