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.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21443 invoked from network); 8 Sep 2022 00:03:17 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Sep 2022 00:03:17 -0000 Received: (qmail 9270 invoked by uid 550); 8 Sep 2022 00:03:13 -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 9238 invoked from network); 8 Sep 2022 00:03:12 -0000 Date: Wed, 7 Sep 2022 20:03:00 -0400 From: Rich Felker To: James Y Knight Cc: musl@lists.openwall.com, Javier Steinaker Message-ID: <20220908000259.GH9709@brightrain.aerifal.cx> References: <20220907204935.GG9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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 > >