Re: Fix overflow in DecodeInterval
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2022-04-03T16:30:32Z
Lists: pgsql-hackers
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
Commits
-
Fix portability issues in datetime parsing.
- 591e088dd5b3 15.0 landed
-
Fix overflow hazards in interval input and output conversions.
- e39f99046710 15.0 landed
-
Add a couple more tests for interval input decoding.
- 1b208ebaf14e 15.0 landed