[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2f25222-ac77-6066-cd3d-68ba5513416d@wobble.ninja>
Date: Thu, 1 Oct 2020 10:08:17 +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?
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!
On 10/1/20 7:24 AM, Ellie wrote:
> 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.
