[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220908000259.GH9709@brightrain.aerifal.cx>
Date: Wed, 7 Sep 2022 20:03:00 -0400
From: Rich Felker <dalias@...c.org>
To: James Y Knight <jyknight@...gle.com>
Cc: musl@...ts.openwall.com, Javier Steinaker <jsteinaker@...il.com>
Subject: Re: strptime_l implementation
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@...c.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
> >
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.
