Re: BUG #18247: Integer overflow leads to negative width

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Fri, Dec 15, 2023 at 2:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com>
>> Your patch looks good to me, but maybe you would find it suitable to fix in
>> passing one more integer overflow in costsize.c?

> Nice catch. The overflow occurs when cost_bitmap_heap_scan() calls
> compute_bitmap_pages(), and the loop_count parameter is converted from
> double to int. I wonder if we can change the loop_count parameter to be
> double for compute_bitmap_pages() to avoid such overflow.

Yeah. Seems like a flat-out error in da08a6598: that logic had been
treating loop_count as double for years, and then when it was split
out into a subroutine, somebody carelessly declared the argument as
int. (Even sillier, all the callers are trying to pass doubles.)

compute_bitmap_pages is substantially below par as to commenting,
too.

However, I'd be a bit uncomfortable about back-patching; since that
function is globally exposed, it's at least possible that some
extension is calling it and would see an ABI break. Is it good enough
to fix this in HEAD? I'd argue yes, given that a loop_count larger
than INT_MAX seems like a pretty improbable case.

regards, tom lane