Re: query_int wrongly parses zero-padded input

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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