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 16:44:46 |
Message-ID: | CAAvxfHfXu+7axue29Sw3pzbyG4j371ZJa1r+z20icQff91kiBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-04-03 16:50:02 | Re: Add index scan progress to pg_stat_progress_vacuum |
Previous Message | Andres Freund | 2022-04-03 16:39:23 | Re: Enables to call Unregister*XactCallback() in Call*XactCallback() |