On Wed, Sep 07, 2022 at 06:46:32PM -0400, James Y Knight wrote:
> Someone in 2016 compared POSIX, cygwin, and glibc's list of locale_t
> functions: https://www.mail-archive.com/cygwin@cygwin.com/msg149338.html

If I'm reading that correctly, is the full list of nonstandard
extensions is:

{is,to}ascii_l
{str,wcs}to{l,ll,ul,ull,d,f,ld}_l
wcsftime_l
strptime_l

and the ones we're lacking are:

{is,to}ascii_l
{str,wcs}to{l,ll,ul,ull}_l
wcsto{d,f,ld}_l
strptime_l

If this is actually complete, strptime_l is the only one that would
not just be a pure thunk to throw away the locale_t arg.

From the above list, {is,to}ascii_l seem like junk I'd be inclined to
omit. They're _l versions of deprecated functions that should not be
used.

I'm not sure about {str,wcs}to{l,ll,ul,ull}_l. My leaning is that it's
misguided for apps to be using them. Their behavior is not locale
dependent per the standard, except possibly for admiting additional
locale-specific sequences to be interpreted as numbers. Perhaps that's
the rationale: being able to suppress that allowance by making a
LC_NUMERIC=C locale object and ensure only standard sequences are
supported. So these seem like a maybe.

wcsto{d,f,ld}_l should clearly be added for consistency with
strto{d,f,ld}_l which we already have.

strptime_l then seems like it can just be considered on its own
merits.


> 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
> >