On Sun, 2012-12-09 at 17:45 -0500, Tom Lane wrote:
> Yeah. After looking at other uses of my_log2, it seems like
> hash_estimate_size and hash_select_dirsize probably should also
> bound their inputs to avoid overflow of 1 << my_log2() calculations.
>
> 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.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
