mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Javier Steinaker <jsteinaker@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] strptime_l implementation
Date: Wed, 7 Sep 2022 16:49:36 -0400	[thread overview]
Message-ID: <20220907204935.GG9709@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAKKDgxZJLE5icr5dB4vWzgAQeQ_y+D1nPUVF+4PkvKznXHPn8w@mail.gmail.com>

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

  parent reply	other threads:[~2022-09-07 20:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-07 19:36 Javier Steinaker
2022-09-07 20:06 ` Markus Wichmann
2022-09-07 20:49 ` Rich Felker [this message]
2022-09-07 22:46   ` James Y Knight
2022-09-08  0:03     ` Rich Felker
2022-09-08  0:23       ` Javier Steinaker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220907204935.GG9709@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=jsteinaker@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).