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 11209 invoked from network); 1 Oct 2020 07:35:06 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2020 07:35:06 -0000 Received: (qmail 12127 invoked by uid 550); 1 Oct 2020 07:34:58 -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 16344 invoked from network); 1 Oct 2020 05:24:31 -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> Message-ID: <805b0ccb-5f71-afdf-8898-6d5a9435d10b@wobble.ninja> Date: Thu, 1 Oct 2020 07:24:19 +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: <03e1484f-0f66-b86a-d717-45ee1eb32790@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? 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 >>