Re: query_int wrongly parses zero-padded input

Manu <manuelreyesbravo(at)gmail(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Oh, that's an excellent point: if we did want to go the direction of
>> exposing strtol's full behavior, we'd need to make the code check
>> that strtol ate the whole input, which it does not today. I think
>> it's unnecessary to add such a check if we switch to base 10
>> (maybe I'm wrong?).

> I think you're right, and I measured it rather than reason about it.

Really? Maybe you proved something about the specific strtol
implementation you tested, but it's a wide world out there.

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. POSIX seems to require the
endptr to be placed after the last digit --- but if we don't
ask for an endptr value, the library would be well within its
rights to not scan all the way to the end. However, 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.

Now that I'm looking at the POSIX spec, there's also this
fun tidbit:

In other than the C or POSIX locale, additional locale-specific
subject sequence forms may be accepted.

The Linux/glibc man page mentions this but does not indicate that
glibc actually implements any such thing; but perhaps other platforms
do. I think this provision is moot as long as the input can only
contain a sign followed by ASCII digits. But if we accepted other
characters, that could be another route to strtol deciding that the
string is acceptable but has trailing junk.

In short, I concur that we shouldn't need a trailing-junk check
given the current parsing behavior; but I think the safe way to
arrive at that conclusion is by reading the POSIX standard
not by exhaustively testing one specific version of one
specific library.

regards, tom lane