Better/more strtol variants

[Olaf van der Spek]

On Wed, Mar 26, 2014 at 5:33 PM, Roland McGrath <roland@hack.frob.com> wrote:
> In general this sort of slight interface improvement is not sufficient
> justification to complicate the API with something that duplicates the
> functionality of a standards-specified interface.  Most applications will
> want to use the standard interface for portability anyway (even just to
> this year's glibc-based systems, since a new API wouldn't find its way into
> wide deployment for at least a year, probably longer).

Where do we want to be in 5 years? In 15 years?
True, it won't immediately be globally available, but I don't think
that's a reason not to consider improvements.
Being able to parse non-null-terminated inputs, along with the other
improvements, is IMO not a slight improvement.
Current code has to resort to hacks like writing a \0 into the input
buffer which should've been const, parsing the number and restoring
the original value.
Some code also allows leading whitespace but not trailing whitespace,
which can't be what was intended, right?

-- 
Olaf