From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15495 invoked from network); 1 Oct 2020 08:18:55 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2020 08:18:55 -0000 Received: (qmail 19890 invoked by uid 550); 1 Oct 2020 08:18:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9710 invoked from network); 1 Oct 2020 08:08:29 -0000 From: Ellie To: Rich Felker Cc: musl@lists.openwall.com References: <47f2d2dc-0f18-5d86-8206-1196502b60e0@wobble.ninja> <20201001023528.GM17637@brightrain.aerifal.cx> <03e1484f-0f66-b86a-d717-45ee1eb32790@wobble.ninja> <805b0ccb-5f71-afdf-8898-6d5a9435d10b@wobble.ninja> Message-ID: Date: Thu, 1 Oct 2020 10:08:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <805b0ccb-5f71-afdf-8898-6d5a9435d10b@wobble.ninja> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [musl] 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 >>>