mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Ellie <kittens@wobble.ninja>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Would it to be possible to get strtoll_l?
Date: Thu, 1 Oct 2020 10:08:17 +0200	[thread overview]
Message-ID: <f2f25222-ac77-6066-cd3d-68ba5513416d@wobble.ninja> (raw)
In-Reply-To: <805b0ccb-5f71-afdf-8898-6d5a9435d10b@wobble.ninja>

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
>>>

  reply	other threads:[~2020-10-01  8:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01  0:34 ell1e
2020-10-01  2:35 ` Rich Felker
2020-10-01  4:36   ` ell1e
2020-10-01  5:24     ` Ellie
2020-10-01  8:08       ` Ellie [this message]
2020-10-01 15:47         ` Rich Felker
2020-10-07 13:44           ` ell1e
2020-10-07 13:52             ` Ellie
2020-10-07 14:58               ` 罗勇刚(Yonggang Luo)
2020-10-07 15:41             ` Ariadne Conill
2020-10-07 19:37             ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2f25222-ac77-6066-cd3d-68ba5513416d@wobble.ninja \
    --to=kittens@wobble.ninja \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).