From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joseph Koshakow <koshy44@gmail.com>
cc: Andres Freund <andres@anarazel.de>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Fix overflow in DecodeInterval
In-reply-to: <CAAvxfHdYRpNNDt==S67HNrx9USBTy=R3NCVqDopfxNifKT-mZQ@mail.gmail.com>
References: <CAAvxfHff0JLYHwyBrtMx_=6wr=k2Xp+D+-X3vEhHjJYMj+mQcg@mail.gmail.com> <2176379.1644612942@sss.pgh.pa.us> <CAAvxfHd-DZzRC9wROFbsZq=8zK+R-5G7DAoZ-oUK8n09cGA0eA@mail.gmail.com> <CAAvxfHddHqA=dDKrbi+d+vo52j=sUwVt6_PYOsJGo+Eq91v4=g@mail.gmail.com> <20220213035150.wusl6mmbeb3m3jpy@alap3.anarazel.de> <CAAvxfHdrQc8pVoSnTPBfTKzHQzmYTg1qheNxMLoWDcrWpTJapg@mail.gmail.com> <20220213203037.ie7bgjrodupzxhda@alap3.anarazel.de> <2726280.1644784719@sss.pgh.pa.us> <CAAvxfHd3gsOkGsbu5AVG+ayHiqsWzuZsi8WknL7v4C_A_4TwOQ@mail.gmail.com> <CAAvxfHeNNjsJarnzVOycP__T2x4iwbbSWBDaDePcuBjz8--x6Q@mail.gmail.com> <20220215162809.yryv7bj24lxfoo37@alap3.anarazel.de> <CAAvxfHfKYHw8n19s7eAcDo_B2T1SS22O1p0X4OE5_WBK230O+Q@mail.gmail.com> <CAAvxfHduBhZdUXLFwLOSGW=0c17frLojcbCqNsZrw5n73pekZg@mail.gmail.com> <CAAvxfHdVaHrriTWyvsLg3POX13rOyUGysur59sOT02qmmTq0Rg@mail.gmail.com> <410974.1645400227@sss.pgh.pa.us> <CAAvxfHdQGiX2xC78y3Y_LTdCiTOWtMXkaLai7s7-mG+=H7qNXA@mail.gmail.com> <CAAvxfHd730o24gGhu5YoL1Sxt!
 0B=KfoL5aq5uttufjqLEiKitA@mail.gmail.com> <CAAvxfHdM_8rhBP+GLj_9rSHswjBESztrxEV+GrTvXv9fAnBUfQ@mail.gmail.com> <CAAvxfHecFFqpn=5H0T3N1Bki=rkgW0BmRNOZ1NZdKDMCOoy+Rw@mail.gmail.com> <1523458.1648926618@sss.pgh.pa.us> <CAAvxfHf8mXDaCjHmvDHNcKw8o8+cBOHiB+nE5ea9_a-1oiVS0Q@mail.gmail.com> <1531188.1648930455@sss.pgh.pa.us> <1592893.1648969747@sss.pgh.pa.us> <CAAvxfHcKD3FGw6AseTLqMtwoY4a=rmCR6AXQ997Av611yrSbrA@mail.gmail.com> <1640460.1649000698@sss.pgh.pa.us> <1642579.1649001803@sss.pgh.pa.us> <CAAvxfHdYRpNNDt==S67HNrx9USBTy=R3NCVqDopfxNifKT-mZQ@mail.gmail.com>
Comments: In-reply-to Joseph Koshakow <koshy44@gmail.com>
	message dated "Sun, 03 Apr 2022 12:22:12 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1645292.1649003432.1@sss.pgh.pa.us>
Date: Sun, 03 Apr 2022 12:30:32 -0400
Message-ID: <1645293.1649003432@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1645293.1649003432%40sss.pgh.pa.us>
Precedence: bulk

Joseph Koshakow <koshy44@gmail.com> writes:
> On Sun, Apr 3, 2022 at 12:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Oh ... a bit of testing says that strtod() on an empty string
>> succeeds (returning zero) on Linux, but fails with EINVAL on
>> AIX.  The latter is a lot less surprising than the former,
>> so we'd better cope.

> I'm not sure I follow exactly. Where would we pass an empty
> string to strtod()? Wouldn't we be passing a string with a
> single character of '.'?

Oh, I was thinking that we passed "cp + 1" to strtod, but that
was just caffeine deprivation.  You're right, what we are asking
it to parse is "." not "".  The result is the same though:
per testing, AIX sets EINVAL and Linux doesn't.

> 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.

			regards, tom lane