Re: Fix overflow in DecodeInterval
От | Tom Lane |
---|---|
Тема | Re: Fix overflow in DecodeInterval |
Дата | |
Msg-id | 1645293.1649003432@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fix overflow in DecodeInterval (Joseph Koshakow <koshy44@gmail.com>) |
Ответы |
Re: Fix overflow in DecodeInterval
|
Список | 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
В списке pgsql-hackers по дате отправления: