[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <805b0ccb-5f71-afdf-8898-6d5a9435d10b@wobble.ninja>
Date: Thu, 1 Oct 2020 07:24:19 +0200
From: Ellie <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?
Just to add to this after even more thinking, it also seems conceptually
weird to me: why litter additional calls at all when a parameter would
do? Why "fight" any untrusted function by reverting locale changes, or
alternatively "protect" all my own calls against unexpected locale
evildoers when I could just specify all the info with parameters instead
of half of it? It's not like the string functions are already
overflowing with parameters right now.
It just seems like a weird design to me, personally. On the BSDs, the
*_l() functions seem to commonly exist by default (not guarded with
_GNU_SOURCE or other extension macros), I assume it's because they
likely thought similarly that the state machine setlocale/uselocale
approach just is oddly clumsy in comparison.
But maybe that's just me?
Regards,
ell1e
On 10/1/20 6:36 AM, ell1e wrote:
> 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.
