Jeff Davis <pg...@j-davis.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
