From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: victor@magic.io
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15519: Casting float4 into int4 gets the wrong sign instead of "integer out of range" error
Date: Fri, 23 Nov 2018 18:03:47 -0500
Message-ID: <13162.1543014227@sss.pgh.pa.us> (raw)
In-Reply-To: <874lc7sb1a.fsf@news-spur.riddles.org.uk>
References: <15519-4fc785b483201ff1@postgresql.org>
<874lc7sb1a.fsf@news-spur.riddles.org.uk>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, victor@magic.io, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15519: Casting float4 into int4 gets the wrong sign instead of "integer out of range" error
In-Reply-To: <13162.1543014227@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox