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,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24537 invoked from network); 7 Sep 2022 20:06:38 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2022 20:06:38 -0000 Received: (qmail 27730 invoked by uid 550); 7 Sep 2022 20:06:35 -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 27698 invoked from network); 7 Sep 2022 20:06:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1662581183; bh=RuRuRsQxDzDxMu6xNd+fJC3m24x/ZwjzzV91O+x1tpQ=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=Jqi/25w3rwHE2Z+oDVzQp5BKDJfntv8Nrdwce+yguKxtBjoE4kNNACY+a6GTUUatc Mvt5L1BkeSFKMZkdE0xWe96VsNeR9sAw0GzNA0FaWlMybrz2v684rYtIJSjo5mqDqd TLpZipGTZVyrx6RFwhpzSqSe89xrxXnsHq6jDTAM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Wed, 7 Sep 2022 22:06:22 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220907200622.GC1649@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:mSzIcyWVxPAiSJ7WLobWcVhyk1d/HdiLhst3JGdQyCc6nsfO2Uk lme85gJMm0DzCT8BruCtK/5Ci/ngMg4jhOgil4ScnG+p5ZQRTv0I3WVwJGfK55TJwSM1p7w W+E4pF5oLRpR6597PR8i3bzdedL7Vs48E9aLuwJThDONyJnxp6I8bTFWZxLSCv4wmKBvDp+ YDF4nVdp+aBK9W+GcT9FA== X-UI-Out-Filterresults: notjunk:1;V03:K0:O9NIE3opVIg=:3U84b1SJMUCJtBzYaun7nu BA/Ghx1HilGPq2IXC95CJwJQyCS0sikFanfIwIzxLc69QwDy4jGmRZtAlr1e6pEG1lYB587Dv j8K8gFW/DO0wUpW3LzpShgZb7uI3NJavfZi4CPDwdQUb9KFDcQjncB+B6kylqkPXIvw8C3tGn Vb64RChteg00FGF9ByhoA58zQOeoNJtQwjquM0y+/WhgfpuuF7Do9UBSsJNcHrCl3Dg+oiPen ZDAVfzUMjMoKOJ1iauQ2EavTSSjnyhud9o38uPyl4rzQIL/poL4vhogMjWYPSzm8rETxlwRK5 S2rCNyauUsRkFl4h/9pWr4sUjEpG3rMtPuP9w1voJEFiMuHciiIiHjARDSaH6kSo0H8z9OvMb JMwQTs4trtjAREJwoCIWuWkX7y8/yToL5L+fCEQvDV0KC7mLh1RqtDKXjGYKv8LEL5kkRrcKi pdjL2XkXBjZRyyx4VvSv0viYWQoC7Y3qSE5viXonZND86T0cJIC8BGfWY7xX/IemDU1mwFGAD Ot+1x+xBFt7eVz09F37sjWfkAbTwMy1oDHf41fyAcDS3oGqSBeMPychb41Ycy+5HHFzac0ns2 L6Hvt+3dZGlxYATpp8l5do7qmsM6sDXaJ5sauwwQzu0UvoRYfH8YpLPMZuZi0aeidXBjM+71J SNCePH6CAmp/M5pbEZVNxX05sngaYgbdnx2hDrb5ih+PBFeypaI3utBOVfyqu3PYV4/okqwhB t6tB30M7JmgN2kfe/6oN2MpkMU4es2eIYlvbFeDrEmOb/7l8iZUblNP0DmGZ3H05CG4ReF2S0 vK4NvxACQD8yHERJ1g4dYghveaMNfGNXp2VL9l+8nRq08CLyxUKqim7kPeR14GDWssrjrvXs4 KV+TblUG+QJ5si/WK9N95uMoNElSl70ODuooj88VH3JMwRrSOzzAdrjAwMDCpC+y+Fjc+dzow Jhx7DO4X9Ru7h8WPMh1oMraWAI88TfJ+ECobJ1Bq/Qp4Psk1CkTxuS6raA/a5wSQXsvqan0fi 80r9zM1El/1/F8fvbt4T3Rc8lbj+Sr2/2+oA9OeHGQIuycR2+NO+xXtTDystLlOiawk5p/Z6H jnaiEebMQbSOxgd+UKtjQrNUyZ9CBTnhS4BaFt/BH/DK032WWzduPakwMJNmkdsndw8Z++1Yw 2ssKS7c27ZiibsaLaLApKo04a0 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] strptime_l implementation 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 ar= e > always in english, independently of the locale selected by the user). Si= nce > 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 hav= e > 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 upstre= am > and then don't having to maintain a separate version if it was useful he= re. > Otherwise, we will just find our way in the Haiku code, via implementing > strptime_l or with another solution. > > Thanks in advance, > Javier Standard requirements for inclusion are absolutely any kind of standardization effort or agreement among libcs. Otherwise we run the risk that later on, a different version is standardized, and then we cannot change our version without breaking ABI. No, at this point, adding strptime_l would not break ABI, but if we had to change the interface later on, then it would. So better to only add it once everything is coordinated. And if I search for the proposed name of the function, I find a manpage for Illumos, one for Gnulib, and one at mkssoftware.com. That last one claims that strptime_l() is conformant to POSIX, but I failed to find it in POSIX, so I think that claim is wrong. So basically, that is one necessary condition I do not find fulfilled here. Ciao, Markus