|
Message-ID: <03e1484f-0f66-b86a-d717-45ee1eb32790@wobble.ninja> Date: Thu, 1 Oct 2020 06:36:43 +0200 From: ell1e <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? 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.