Thread: money type overflow checks

money type overflow checks

From
Peter Eisentraut
Date:
The input function of the money type has no overflow checks:

=> select '12345678901234567890'::money;
            money
-----------------------------
 -$13,639,628,150,831,692.72
(1 row)

The tests in the regression test file money.sql are bogus because they
only test the overflow checks of the bigint type before the cast.

Here is a patch that adds appropriate checks and tests.  We could
probably remove the bogus tests.

(Is checking for < 0 a valid overflow check?  We save the sign until the
very end, so it ought to work.  The code in int8.c works differently there.)

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

Re: money type overflow checks

From
Tom Lane
Date:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> The input function of the money type has no overflow checks:

Ugh.

> (Is checking for < 0 a valid overflow check?

No, I don't think it's sufficient after a multiplication by 10.  That
would be enough to shift some bits clear out of the word, but there's
no certainty that the new sign bit would be 1.

The scheme used in scanint8 is safe.  But I think it was written that way
mainly to avoid hard-wired assumptions about how wide int64 is, a
consideration that's a mite obsolete now.  You could possibly avoid the
cost of a division by relying on comparisons to PG_INT64_MAX/10.
        regards, tom lane



Re: money type overflow checks

From
Peter Eisentraut
Date:
On 8/5/16 1:14 PM, Tom Lane wrote:
> No, I don't think it's sufficient after a multiplication by 10.  That
> would be enough to shift some bits clear out of the word, but there's
> no certainty that the new sign bit would be 1.
>
> The scheme used in scanint8 is safe.  But I think it was written that way
> mainly to avoid hard-wired assumptions about how wide int64 is, a
> consideration that's a mite obsolete now.

OK, I did it like int8, and added more tests.  My original patch didn't
get the most negative integer right.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment