Re: BUG #15519: Casting float4 into int4 gets the wrong sign instead of "integer out of range" error

=?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