From: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-03 17:00:48 |
Message-ID: | CAAvxfHfQG6fe6Xut1GXdYAzH9KyLsdUfJq_QDvLPmPSX_5+pRQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Apr 3, 2022 at 12:44 PM Joseph Koshakow <koshy44(at)gmail(dot)com> wrote:
>
> On Sun, Apr 3, 2022 at 12:30 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Joseph Koshakow <koshy44(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-parsing-trailing-decimal-point-in-ISO8601.patch | text/x-patch | 5.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-04-03 17:19:38 | Re: unlogged sequences |
Previous Message | Andres Freund | 2022-04-03 16:50:02 | Re: Add index scan progress to pg_stat_progress_vacuum |