Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Oct 2020 06:36:43 +0200
From: ell1e <>
To: Rich Felker <>
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

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.