[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Oct 2020 06:36:43 +0200
From: ell1e <kittens@...ble.ninja>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Would it to be possible to get strtoll_l?
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
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
