Re: Fix overflow in DecodeInterval
Joseph Koshakow <koshy44@gmail.com>
From: Joseph Koshakow <koshy44@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-03T17:00:48Z
Lists: pgsql-hackers
Attachments
- 0001-Fix-parsing-trailing-decimal-point-in-ISO8601.patch (text/x-patch) patch 0001
On Sun, Apr 3, 2022 at 12:44 PM Joseph Koshakow <koshy44@gmail.com> wrote: > > On Sun, Apr 3, 2022 at 12:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > Joseph Koshakow <koshy44@gmail.com> writes: > > > So I think we need to check that endptr has moved both after > > > the call to strtoi64() and strtod(). > > > > I'm not sure we need to do that explicitly, given that there's > > a check later as to whether endptr is pointing at \0; that will > > fail if endptr wasn't advanced. > > > > The fix I was loosely envisioning was to check for cp[1] == '\0' > > and not bother calling strtod() in that case. > > Ah, ok I see what you mean. I agree an approach like that should > work, but I don't actually think cp is null terminated in this case. The > entire Interval is passed to DecodeISO8601Interval() as one big > string, so the specific number we're parsing may be somewhere > in the middle. > > If we just do the opposite and check isdigit(cp[1]) and only call > strtod() in that case I think it should work. > > - Joe Koshakow How does this patch look? I don't really have any way to test it on AIX. - Joe Koshakow
Commits
-
Fix portability issues in datetime parsing.
- 591e088dd5b3 15.0 landed
-
Fix overflow hazards in interval input and output conversions.
- e39f99046710 15.0 landed
-
Add a couple more tests for interval input decoding.
- 1b208ebaf14e 15.0 landed