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

From Tom Lane
Subject Re: Small and unlikely overflow hazard in bms_next_member()
Date
Msg-id 3190647.1775103768@sss.pgh.pa.us
Whole thread Raw
In response to Small and unlikely overflow hazard in bms_next_member()  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Small and unlikely overflow hazard in bms_next_member()
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> When testing some ERROR code I added to ensure we don't get an
> excessively large left shift value and end up with members higher than
> INT32_MAX, I discovered that bms_next_member() can't handle that
> value, as "prevbit++" will wrap to INT32_MIN and then we'll try to
> access a negative array index, i.e. seg fault.

> I appreciate that such a large member is quite unlikely,

I think it's impossible, and if it's not then this is not the
only place in bitmapset.c that could theoretically overflow.
As an example, bms_prev_member does

    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 don't think we should add cycles here for this purpose.
If it makes you feel better, maybe add Asserts to
bms_make_singleton and bms_add_member to constrain the
maximum member value to somewhat less than INT_MAX?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: pg_test_timing: fix unit typo and widen diff type
Next
From: Tom Lane
Date:
Subject: Re: LLVM 22