This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Better/more strtol variants
- From: Olaf van der Spek <ml at vdspek dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 27 Mar 2014 13:14:32 +0100
- Subject: Re: Better/more strtol variants
- Authentication-results: sourceware.org; auth=none
- References: <CAGVGHmv5D8VaPT+Tj3996B7HgWRzuBYqhyWDYhrOwdeXDG-S1A at mail dot gmail dot com> <20140326163334 dot A7F8C74430 at topped-with-meat dot com>
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