| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix overflow in DecodeInterval |
| Date: | 2022-04-02 19:08:24 |
| Message-ID: | 1523268.1648926504@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Joseph Koshakow <koshy44(at)gmail(dot)com> writes:
> Ok I actually remember now, the issue is with the rounding
> code in AdjustFractMicroseconds.
> ...
> I believe it's possible for `frac -= usec;` to result in a value greater
> than 1 or less than -1 due to the lossiness of int64 to double
> conversions.
I think it's not, at least not for the interesting range of possible
values in this code. Given that abs(frac) < 1 to start with, the
abs value of usec can't exceed the value of scale, which is at most
USECS_PER_DAY so it's at most 37 or so bits, which is well within
the exact range for any sane implementation of double. It would
take a very poor floating-point implementation to not get the right
answer here. (And we're largely assuming IEEE-compliant floats these
days.)
Anyway, the other issue indeed turns out to be easy to fix.
Attached is a v11 that deals with that. If the cfbot doesn't
complain about it, I'll push this later today.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v11-0001-Check-for-overflow-when-decoding-an-interval.patch | text/x-diff | 96.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-04-02 19:10:18 | Re: Fix overflow in DecodeInterval |
| Previous Message | Joseph Koshakow | 2022-04-02 18:55:13 | Re: Fix overflow in DecodeInterval |