Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "PG" == PG Bug reporting form <noreply@postgresql.org> writes:
> PG> Offending examples:
> PG> SELECT ((2147483647::float4) - 1.0::float4)::int4;
> PG> SELECT ((2147483590::float4) - 1.0::float4)::int4;
> PG> SELECT ((2147483647::float4) + 1.0::float4)::int4;
> PG> They all produce the same result: -2147483648
> The bug here is that the ftoi4 conversion function thinks it can do
> this:
> if (num < INT_MIN || num > INT_MAX || isnan(num))
> Probably this should be changed to use ((float8) INT_MAX) etc. instead?
After thinking about this for awhile, there's another class of undesirable
behavior here, which can be illustrated by
regression=# select '32766.1'::float4::int2;
int2
-------
32766
(1 row)
regression=# select '32767.1'::float4;
float4
---------
32767.1
(1 row)
regression=# select '32767.1'::float4::int2;
ERROR: smallint out of range
It doesn't seem very nice that that fails rather than producing 32767.
I think we could fix that by doing the rint() first, before the
comparisons, which should be safe enough: as the Linux man page for it
points out, it really can't ever fail.
I'm inclined to write ftoi4 as
/*
* Get rid of any fractional part in the input. This is so we don't
* fail on just-out-of-range values that would round into range.
*/
num = rint(num);
/*
* Range check. We must be careful here that the boundary values are
* expressed exactly in the appropriate float domain; we assume float4
* is going to round off INT_MAX to a power of 2. Also note assumption
* that rint() will pass through a NaN or Inf unchanged.
*/
if (unlikely(num < (float4) INT_MIN || num >= (float4) INT_MAX || isnan(num)))
ereport(...);
PG_RETURN_INT32((int32) num);
We could use the same pattern for the other five functions at issue,
but "num >=" would be "num >" in cases where we expect the comparison
value to be represented without roundoff.
Obviously, some regression test cases to verify all these assumptions
would be a good idea.
regards, tom lane
