Re: Fix overflow in DecodeInterval - Mailing list pgsql-hackers

From Joseph Koshakow
Subject Re: Fix overflow in DecodeInterval
Date
Msg-id CAAvxfHfXu+7axue29Sw3pzbyG4j371ZJa1r+z20icQff91kiBQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix overflow in DecodeInterval  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fix overflow in DecodeInterval  (Joseph Koshakow <koshy44@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Enables to call Unregister*XactCallback() in Call*XactCallback()
Next
From: Andres Freund
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum