Re: [musl] Would it to be possible to get strtoll_l?

[Rich Felker <dalias@libc.org>]

On Thu, Oct 01, 2020 at 10:08:17AM +0200, Ellie wrote:
> Hah, sorry for the e-mail spam, I'm only now just realizing I read over
> your latest remark that strtoll doesn't really change in behavior.
> 
> Yeah, I have actually be wondering how strtoll even could be
> locale-specific, but assumed surely there'd be some corner case I don't
> know about.
> 
> But if that makes it just an alias of strtoll effectively, would it be
> possible to add strtoll_l to musl just for the sake of completion? Since
> it exists for most platforms (glibc, bsd, windows) who knows how this
> will be changed to behave in the future, I'd rather use the "proper"
> function and be on the safe side.
> 
> In any case, thanks for the insightful response!

A *complete* set of *_l functions (for all operations that are
locale-dependent) would be rather large, and would include a lot that
don't really admit such thin implementations e.g. because they'd have
variadic signatures. It looks like the set chosen for standardization
mostly covered just the ones where the function itself was expected to
be so small/fast that setting the thread-local locale around the call
would be relatively expensive, but some don't fit that pattern, like
strftime_l. And then on top of that, we seem to have a somewhat
inconsistent coverage set for non-standardized BSD/GNU extensions --
wcsftime_l, strtod_l, etc.

A big part of maintainership, especially for libc, is saying no. In
this case, it might make sense to add a few more nonstandard ones,
especially if we already have most but not all of them and there's a
clear bounded set of what would be supported and they're all things
that admit ultra-thin wrappers. Would you be interested in
investigating that and following up?

Rich