From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11849 invoked from network); 7 Sep 2022 22:47:14 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2022 22:47:14 -0000 Received: (qmail 3616 invoked by uid 550); 7 Sep 2022 22:47:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3583 invoked from network); 7 Sep 2022 22:47:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=sv11FB2GcdHECD+XtfN7OeAh7L0TFzbuuoScRACcrmw=; b=I7bCNBMIQDElNNeGRYtsWNEFWPhkbq0EZt4PaaNL9UjmmMjVBuqTA6kZKLoFjaGHY7 JVW2clBO7UqzuFpoUfjMftFIiKoqXaGWO71PAVx0SK3laN/s4lDY6wjDC5d76R6JYw/n 0U7uxFbEO4yP1QA+m1R5Ko5a1vVKXu6cy/6GJxL4zCfPXL8UbFlae7ETzC/248jprZPM NusVVSE10tAwWNCxsqONNbkLvyQo8qpYhvZ8D/RtgvJFWTkuVTiynYAmEAEpEopBZ2NP zI6DBRHGiwldoT4RzPW2BBX6atl7pouoiSVz0CVxvHC/X2SAwtkn3pBMLjNVfhIjaLPb jCqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=sv11FB2GcdHECD+XtfN7OeAh7L0TFzbuuoScRACcrmw=; b=dbdhwJxIKfWqBbCvr6LTyJJTmt7hSCvyC/kqWBRNCTwloxQscMWLEX14HocWW6ZzRX qMmooyZ4Gs/83Xnm3zzApNq2cgWaClYg13YYC39F5UlNJvF3H0bLOOhmYUKpLxm6a3jE kIXIanNzQcJ6qIuPL54Intm9iBAeeNkEBP6gX/qei9cNhncbtn+Q307M/WxAWSwdXlcm 5e33aOzN6hEG1Kg/2hp1IdE81HFCHEF2L9ZV2ts1s3NXv/AYb+oueiKOnQM4CsONu7H+ ah0tNUveiA9kwuoG7VXFNvR29eDRMR6YolYbmvrN8YXeB7vIsRj8opYq6ADfr4Tbcp+k Dv6g== X-Gm-Message-State: ACgBeo1HiVBIwOa66QdRarNNLhpM6DKYAybAk4L63cjI1LHR8PrPHk3u mkDHK6oONw5rP/c/8zq6xbNHTn2uVVx93S2JRmry/fLb/nwJ1g== X-Google-Smtp-Source: AA6agR6gHPGeJ9GPinISBFo5fJqh0D/H8Z9Lg9E7/VN86otEx638LseNxnU/vpXBAQ0uYrail5J5jceW1udnln+X3z4= X-Received: by 2002:a0d:d9c6:0:b0:348:8af2:6e18 with SMTP id b189-20020a0dd9c6000000b003488af26e18mr751664ywe.126.1662590818320; Wed, 07 Sep 2022 15:46:58 -0700 (PDT) MIME-Version: 1.0 References: <20220907204935.GG9709@brightrain.aerifal.cx> In-Reply-To: <20220907204935.GG9709@brightrain.aerifal.cx> From: James Y Knight Date: Wed, 7 Sep 2022 18:46:32 -0400 Message-ID: To: musl@lists.openwall.com Cc: Javier Steinaker Content-Type: multipart/alternative; boundary="00000000000022922105e81e175e" Subject: Re: [musl] strptime_l implementation --00000000000022922105e81e175e Content-Type: text/plain; charset="UTF-8" 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 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 > --00000000000022922105e81e175e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Someone in 2016 compared POSIX, cygwin, and glibc's li= st of locale_t functions:=C2=A0https://www.mail-archive.com/cygwin@cygwin.co= m/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 wee= ks
> 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 h= ave
> strptime and strptime_l getting the locale from the system in the firs= t
> case and as an argument in the second, and call that code.
>
> My question is: do you have plans to have strptime_l implemented? Woul= d 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 use= ful here.
> Otherwise, we will just find our way in the Haiku code, via implementi= ng
> 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
--00000000000022922105e81e175e--