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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23944 invoked from network); 8 Sep 2022 00:23:39 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Sep 2022 00:23:39 -0000 Received: (qmail 21886 invoked by uid 550); 8 Sep 2022 00:23:36 -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 21849 invoked from network); 8 Sep 2022 00:23:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=gAgVNsRDsygimpCc626RSgU1d1aHIHvE+nvm0XBEwJM=; b=P/LXJx5/q8x0nb4tRwXFu/ckrD4Tb2zPSUeIkILI830MUdy5DrfZOeC0RNN4oWxAwV a9dMT+hUnW/H5pDZc/0n10Ha3baIbDSmVsEsQh+Kehj5El5/g/BMs9ENg8XCC2GOO7uY 2P2GBrew6g54Ws1qs6/XEfYvml+3KJT50aUZ7uyjJWYq1NMDXvR3uX5fd1+8aTnEVk4R Pv6Fy3k0Iz5IMwaFCBDYJJ8qp8Tfj83Dg7iW4g+4epJQ53vQJfjI+ZpoQRl7p307NEjL gnovwcl30+usrP5g61KDHeqt0eVdMlw2pyqgNiIYgzwHFS/1W8CgBlfFbQmv3+UNP7D2 SBhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=gAgVNsRDsygimpCc626RSgU1d1aHIHvE+nvm0XBEwJM=; b=aSXWw3c8tEwZbOvSrcx7uUbwCiynP5tN7Xx8D5dpPXLi9At6PtMgDPfhA6B0mic4iK /5Ah0J75mDDvz4LmFjJhuqcYuLtxJKTGJ7q2Pr9Bu4KZh/2frHczes3iVo+tVgIXUVTQ bsbE/4KTyW/Oz1i5xSMtb7rFU7KHeCD+0/jqUO8PZ9cSHV8vlCzueevjQ6G0F00sOdBn QCZfjVQoFfYiz8RY1LO6imxuVgLTLAK/KeQPsXSISfdE+FYntwJjfROzFMnyYOkjSHjr stS4SZJTarUxijJu5ptUPNbCkq30jp9NZv1SeGM6bVDaB4CYOS085og0iJmkZtbFuvK3 MDCg== X-Gm-Message-State: ACgBeo1CFfTdqzhy1Ou7/PglOrKO/8ORNRHa6GcfkmZRZXUjV0IYvv68 clPLK1E8JrJfhKTJ+9nBM/ENHLqCT9oKAE/05IuwIgiC X-Google-Smtp-Source: AA6agR5EtozRs/0QYQOPMCnwCFQ19F0ekvpnr6sXxzfI/CwFXJxt/GD82tIGCQzjIY5j42U1CpuBC4dNbWHQBZVlO8Q= X-Received: by 2002:a05:600c:3b9f:b0:3a5:45d9:8a69 with SMTP id n31-20020a05600c3b9f00b003a545d98a69mr478059wms.186.1662596603799; Wed, 07 Sep 2022 17:23:23 -0700 (PDT) MIME-Version: 1.0 References: <20220907204935.GG9709@brightrain.aerifal.cx> <20220908000259.GH9709@brightrain.aerifal.cx> In-Reply-To: <20220908000259.GH9709@brightrain.aerifal.cx> From: Javier Steinaker Date: Thu, 8 Sep 2022 10:23:08 +1000 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000f96c1a05e81f6faf" Subject: Re: [musl] strptime_l implementation --000000000000f96c1a05e81f6faf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you all for your kind responses. It seems that the uselocale() approach that Rich suggests is the easiest thing to do for us for now. However, it's nice to see strptime_l being considered. In that case and just out of curiosity since my coding level it's far from the standards seen here, could it be possible to make an internal function that both strptime and strptime_l call providing the locale needed? ABI shouldn't break as long as the interface for calling strptime remains the same, am I right? Thank you again for all the tips and information provided, I really appreciate it. El jue., 8 de septiembre de 2022 10:03, Rich Felker escribi=C3=B3: > 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.htm= l > > 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=3DC 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 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 the= n > 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 usef= ul > > > 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 hav= e > > > 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 > > > > --000000000000f96c1a05e81f6faf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for your kind responses.
<= br>
It seems that the uselocale() approach that Rich= suggests is the easiest thing to do for us for now. However, it's nice= to see strptime_l being considered.

In that case and just out of curiosity since my coding level i= t's far from the standards seen here, could it be possible to make an i= nternal function that both strptime and strptime_l call providing the local= e needed? ABI shouldn't break as long as the interface for calling strp= time remains the same, am I right?

Thank you again for all the tips and information provided, I rea= lly appreciate it.

El jue., 8 de septiembre de 2022 10:03, Rich Felker= <dalias@libc.org> escribi=C3= =B3:
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= 9;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<= br> the rationale: being able to suppress that allowance by making a
LC_NUMERIC=3DC 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> wr= ote:
>
> > 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 a= n use case where
> > > having strptime_l would be desired/useful (parsing web cooki= es, which are
> > > always in english, independently of the locale selected by t= he user).
> > Since
> > > nl_langinfo_l is already in place, I figured out it wouldn&#= 39;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 i= n 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 impleme= nted? 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 t= o 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 som= eone
> > to do a survey of how many there actually are, and whether it mak= es
> > sense to add them all or some well-characterized subset of them. = I
> > don't want to just inconsistently add one here and there, whi= le
> > leaving others missing, and I don't want to get in a situatio= n 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 woul= d 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 call= s to
> > functions that don't have their own *_l version is by calling=
> > uselocale() before/after to save/swap and restore the original lo= cale.
> > This operation costs essentially nothing and is a completely viab= le
> > way to do things.
> >
> > Rich
> >
--000000000000f96c1a05e81f6faf--