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

[ell1e <kittens@wobble.ninja>]

Thinking more about this, this seems like it might be the less
performant option to me, although I'd be happy to take your thoughts on
this:

I'm thinking, it would require me to reset the thread locale before and
after each C call (I'm working in a bytecode VM here), and it seems like
just passing an additional locale parameter is going to be faster. I
haven't benchmarked however, if you doubt this assumption I will look
into it. But it seems to me that an additional parameter is preferable
for a few of the string operations to making 2+ additional calls around
each call into C.

But given the above guess, my spontaneous preference would still be to
rather use strtoll_l(). It is also available in glibc, it's just missing
in musl libc, which is why I sent this e-mail.

On 10/1/20 4:35 AM, Rich Felker wrote:
> On Thu, Oct 01, 2020 at 02:34:47AM +0200, ell1e wrote:
>> Hi everyone,
>>
>> I'm working on a project and since the global state setlocale() seems to
>> be a bit of a mess to rely on, I'm using the *_l() string functions
>> instead. However, musl libc appears to lack strtoll_l() right now, so
>> I'm wondering if that'll be added any time soon?
> 
> The portable way to do this is just calling uselocale() rather than
> passing the locale_t to individual *_l functions. You can even
> implement a fallback strtoll_l as:
> 
> localt_t old = uselocale(l);
> result = strtoll(a,b,c);
> uselocale(old);
> 
> It's slightly more efficient if you keep the uselocale across multiple
> calls, but not that big a deal; uselocale is an extremely light
> operation.
> 
> But is there a reason you don't just want plain strtoll? C allows that
> "additional locale-specific subject sequence forms may be accepted" in
> locales other than the C locale, but does not permit standard
> sequences to be interpreted differently, and in practice I'm not aware
> of implementations that do anything funny here.
> 
> Rich
>