Re: Strange interval arithmetic
От | Michael Fuhr |
---|---|
Тема | Re: Strange interval arithmetic |
Дата | |
Msg-id | 20051130223916.GA27287@winnie.fuhr.org обсуждение исходный текст |
Ответ на | Re: Strange interval arithmetic (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Strange interval arithmetic
|
Список | pgsql-hackers |
On Wed, Nov 30, 2005 at 05:20:54PM -0500, Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: > > I'm looking at all the strtol() calls in datetime.c right now; I > > haven't looked anywhere else yet. Should I bother checking values > > that will be range checked later anyway? Time zone displacements, > > for example? > > Good question. Is strtol guaranteed to return INT_MAX or INT_MIN on > overflow, or might it return the overflowed value? The Open Group Base Specifications say this: Upon successful completion, these functions shall return the converted value, if any. If no conversion could be performed,0 shall be returned and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, {LONG_MIN}, {LONG_MAX}, {LLONG_MIN}, or {LLONG_MAX} shallbe returned (according to the sign of the value), and errno set to [ERANGE]. http://www.opengroup.org/onlinepubs/009695399/functions/strtol.html FreeBSD and Solaris both peg overflow at LONG_MAX, and that behavior is what I noticed in the first place. I don't know if any systems behave otherwise. Alvaro suggested checking for both LONG_MAX and ERANGE; I suppose if we check for LONG_MAX then we should also check for LONG_MIN. I don't know if any systems might set ERANGE in a non-error situation. -- Michael Fuhr
В списке pgsql-hackers по дате отправления: