Tom Lane <[email protected]> writes: > The thing I was wondering about was whether an implementation might stop > short of reading the whole digit string once it realizes it's reached > overflow. [...] that's moot since we check both for errno being set and > for an out-of-int32-range result, both of which should get tripped if the > library does quit early on overflow.
Point taken on the method; reasoning from the code rather than the test, the two checks turn out to be load-bearing on different platforms, which is why neither alone would do. gettoken() caps the operand at 15 characters (nnn[16]), so the value handed to strtol() is at most ~10^15. Where long is 64-bit, that is far below LONG_MAX, so strtol() cannot overflow and errno is never set on this input: an out-of-int32 value is read in full -- no early stop to worry about -- and is rejected only by the explicit "(long) *val != lval" round-trip. Where long is 32-bit, an out-of-int32 operand does overflow strtol(), and POSIX requires ERANGE, which the errno check catches. So the "quit early on overflow" case is confined to platforms with a 32-bit long, and ERANGE covers it there; on a 64-bit long it can't arise. Either way no trailing-junk check is needed. regards, Manu
