From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets |
Date: | 2012-12-11 00:52:36 |
Message-ID: | 333.1355187156@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Sun, 2012-12-09 at 17:45 -0500, Tom Lane wrote:
>> Alternatively, maybe we should hack my_log2 to do that bounding.
>> As-is, it seems like trouble waiting to happen. This won't protect
>> init_htab, which needs the shift result to fit in int not long.
>> But my_log2 is just plain broken for inputs larger than LONG_MAX/2,
>> anyway.
> It looks like all of the callers, except two, immediately shift the
> result. So perhaps it would be better to make a new function (something
> like "ceil_pow2") that returns the lowest power of two greater than or
> equal to the input, and it can return a long (bounded to +LONG_MAX).
> Then, the caller can bound the result further if needed, which should be
> less error-prone, because the caller would see that it returns a long
> (and compiler, but I don't seem to get a warning for implicit long->int
> conversions).
> Both of the callers that actually want a log2 already assume that the
> input is a power of two, so we can redefine my_log2 to require it.
It seems reasonably possible that add-on code is using my_log2, so I'm
hesitant to change the function's signature, or to change its behavior
more than minimally necessary --- especially in the back branches.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-12-11 01:27:22 | Re: init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets |
Previous Message | Jeff Davis | 2012-12-11 00:29:36 | Re: init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets |