Re: [musl] strptime_l implementation

[James Y Knight <jyknight@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]

Someone in 2016 compared POSIX, cygwin, and glibc's list of locale_t
functions: https://www.mail-archive.com/cygwin@cygwin.com/msg149338.html



On Wed, Sep 7, 2022 at 4:49 PM Rich Felker <dalias@libc.org> wrote:

> On Thu, Sep 08, 2022 at 05:36:34AM +1000, Javier Steinaker wrote:
> > Hello everybody,
> >
> > The Haiku project (an alternative OS) switched to using musl a few weeks
> > ago. Now I'm only an occasional contributor, but I hit an use case where
> > having strptime_l would be desired/useful (parsing web cookies, which are
> > always in english, independently of the locale selected by the user).
> Since
> > nl_langinfo_l is already in place, I figured out it wouldn't be so
> > difficult to move the current code to an internal function, and then have
> > strptime and strptime_l getting the locale from the system in the first
> > case and as an argument in the second, and call that code.
> >
> > My question is: do you have plans to have strptime_l implemented? Would
> you
> > be interested in merging if someone does? Would it break the ABI or
> > something? I'm asking because it made more sense to me to do this
> upstream
> > and then don't having to maintain a separate version if it was useful
> here.
> > Otherwise, we will just find our way in the Haiku code, via implementing
> > strptime_l or with another solution.
>
> There are some number of nonstandard *_l functions, some of which have
> been requested for addition. My request on these has been for someone
> to do a survey of how many there actually are, and whether it makes
> sense to add them all or some well-characterized subset of them. I
> don't want to just inconsistently add one here and there, while
> leaving others missing, and I don't want to get in a situation where
> we feel obligated to add a bunch of dubious interfaces just by
> precedent.
>
> If you'd like to make such a list/count, I'm sure it would be
> appreciated by others who have raised the topic before, and might end
> up with the functions getting added.
>
> Short of that, the portable way to do locale_t-parameterized calls to
> functions that don't have their own *_l version is by calling
> uselocale() before/after to save/swap and restore the original locale.
> This operation costs essentially nothing and is a completely viable
> way to do things.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2933 bytes --]