=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> Offending examples:
> SELECT ((2147483647::float4) - 1.0::float4)::int4;
> SELECT ((2147483590::float4) - 1.0::float4)::int4;
> SELECT ((2147483647::float4) + 1.0::float4)::int4;
> They all produce the same result: -2147483648
Huh, interesting. The code underlying this looks sane enough
at first glance:
float4 num = PG_GETARG_FLOAT4(0);
if (num < INT_MIN || num > INT_MAX || isnan(num))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("integer out of range")));
PG_RETURN_INT32((int32) rint(num));
I think what is happening is that the compiler is interpreting
"num > INT_MAX" as something to be done in float4 arithmetic,
so it computes (float4) INT_MAX which rounds off to be the
equivalent of exactly 2147483648. Then the problematic input
values, which all also round to 2147483648, get past the if-test
and result in undetected overflow in the cast to int32.
Perhaps we could fix this by writing
if (num < (float8) INT_MIN || num > (float8) INT_MAX || isnan(num))
but I don't have a huge amount of confidence in that either, especially
not for the similar coding in ftoi8 and dtoi8, where the comparison values
are large enough that they'd not be exactly represented by float8 either.
Maybe we need an explicit check for the integer result being of the wrong
sign, to catch just-barely-overflowing cases like these.
regards, tom lane