On Sun, Apr 3, 2022 at 12:03 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > I wrote: > > Joseph Koshakow <kosh...@gmail.com> writes: > >> I think I know that the issue is. It's with `ParseISO8601Number` and > >> the minutes field "1.". > >> Previously that function parsed the entire field into a single double, > >> so "1." would > >> be parsed into 1.0. Now we try to parse the integer and decimal parts > >> separately. So > >> we first parse "1" into 1 and then fail to "." into anything because > >> it's not a valid decimal. > > > Interesting point, but then why doesn't it fail everywhere? > > 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. > > (Reading POSIX with an eagle eye, it looks like both behaviors > are allowed per spec: this is why you have to check that endptr > was advanced to be sure everything is kosher.) > > regards, tom lane
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 '.'? Either way, from reading the man pages though it seems that strtod() has the same behavior on any invalid input in Linux, return 0 and don't advance endptr. So I think we need to check that endptr has moved both after the call to strtoi64() and strtod(). - Joe Koshakow