Re: Better/more strtol variants

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Mar 27, 2014 at 01:14:32PM +0100, Olaf van der Spek wrote:
> 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?

In a state where software is written to standards and portable to
everywhere, rather than having all kinds of local nonstandard
extensions and quirky semantics that conflict with standards.

> 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

Why? strtol and family stop at the first non-numeric character. Thus
it's easy to parse numbers contained in longer strings. The case where
numbers are packed directly adjacent to one another with no
intervening characters is extremely unusual, and I don't think it's
unreasonable to demand that the application just memcpy the data to a
temporary buffer for this odd usage case.

> 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?

This is easy to solve: you simply check isspace(*str) before passing
str to strtol. And if you want to forbid leading +/- too, you check
isdigit(*str).

I agree it's not the most convenient, but applications are free to
make trivial wrappers which adapt the interface to their needs (which
often vary from appliction to application). Higher-level libraries
like APR, NSPR, glib, etc. are of course welcome to offer wrappers
like this; maybe they already do.

Rich