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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Victor Petrovykh <victor(at)magic(dot)io>
Cc: andrew(at)tao11(dot)riddles(dot)org(dot)uk, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15519: Casting float4 into int4 gets the wrong sign instead of "integer out of range" error
Date: 2018-11-24 01:42:36
Message-ID: 18151.1543023756@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Victor Petrovykh <victor(at)magic(dot)io> writes:
> Am I missing something in thinking that the cast of a float to int should
> produce an error if the sign of the original value doesn't match the sign
> of the cast result?

Well, yeah, our traditional way of coding this overflow check would
probably have compared the sign of the result to the sign of the input,
but (a) we'd still have needed some ad-hoc range check to avoid getting
fooled by inputs large enough to have wrapped around an even number of
times, and (b) this approach depends on the compiler not taking any
liberties based on an assumption that the program doesn't provoke
integer overflow. (b) gets more worrisome with each year that goes by,
because the compiler guys keep finding ever-more-creative ways to break
your code if it violates C-spec semantics. So we really want to write
a test that will fail exactly when the integer coercion would overflow,
not do the coercion and then check to see if it overflowed.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-11-24 10:45:54 BUG #15520: PAM authentication + domain socket -> DNS query for symbolic hostname [local]
Previous Message Victor Petrovykh 2018-11-24 01:16:23 Re: BUG #15519: Casting float4 into int4 gets the wrong sign instead of "integer out of range" error