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 11188 invoked from network); 1 Oct 2020 07:35:05 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2020 07:35:05 -0000 Received: (qmail 12118 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 32073 invoked from network); 1 Oct 2020 04:36:56 -0000 To: Rich Felker Cc: musl@lists.openwall.com References: <47f2d2dc-0f18-5d86-8206-1196502b60e0@wobble.ninja> <20201001023528.GM17637@brightrain.aerifal.cx> From: ell1e Message-ID: <03e1484f-0f66-b86a-d717-45ee1eb32790@wobble.ninja> Date: Thu, 1 Oct 2020 06:36:43 +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: <20201001023528.GM17637@brightrain.aerifal.cx> 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? 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 >