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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 21045 invoked from network); 7 Sep 2022 19:37:02 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2022 19:37:02 -0000 Received: (qmail 11630 invoked by uid 550); 7 Sep 2022 19:37:00 -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 11597 invoked from network); 7 Sep 2022 19:36:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=qPsK4NZdXa8Fqp8LoGx4sBjoVzYOqmRWiwoYmQjaclo=; b=lSME/PgF8Px58IJZbMELSuBdyrDcgSEJK49hKxfzwsVKw0h5ZGClnokcEJp0MJqZf9 PEo6LFaM38SRM2VswWPCgE3Ml1ZPh328RoHxpQrLbXESoDF2fq8gJMGoOYA+aFtUGUf1 dAF/yb9AN/5gnyjpZWhiiQWUbBdXqTRRlJgSMW3XGZW2sR8PX7/PnkRRzoTmdGfsjMZq M4K7aKG4utJwLP9woeLDW3+XQL+J1V/NkJ7TIXkFXNoIu/xWKSOpvYclWFA5LthHCbfW dyDcHY2CU3WyjnbokITMwZFfcJfdQLAQK5RzwBPd8rmlDeE02iqFe2aBhlL+YXSm3EQe cGLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=qPsK4NZdXa8Fqp8LoGx4sBjoVzYOqmRWiwoYmQjaclo=; b=iFdcCYfwUd4Sn9ewi6MeGB8sWdi9FiwCRmJWuqPPQyqtNZZusgo7iwWasXJAvvVhTj Kqcsx0aYanxx3pWte/TFrCfv2VXfLzWdCurlH0Ih+R6iqDPjNt/LgRxsO5+yznKMeP6N 1uUbiUyE/TZ2YqaHMfTfMofFePHd60dBB5ERHtxmFCD0ugbhMNlWKPeoYEzv1GgNsqyb qCuR1uw7hIO1ijH8KwxYFgd8STr1sZBC/AaJ2u07UItxg4nJGQ/wCejmEt9x88IYxx7T Yjxf6+7Krun++/J4mknmHAp9YAHgARLNmZkgvSfsTxeu7R4TIaxgLQf5/9H6UgyFXM+O Vtag== X-Gm-Message-State: ACgBeo0RqqrOp2+VDUEcchyt9QGTS9nZokBK+XfHLnJOXc2UdU/5LXHl eNhixTYcv5VvhhbOEcX1Brt66DxT57GLXnF919c2UOhm X-Google-Smtp-Source: AA6agR7CW+uDsgL6e5QK4I9z5iR470J2LF9QTEcDGPMCtuyZJjsU5KcZprdCIFu82T1FG9lU/PdVPMBOJzQL5QAUDds= X-Received: by 2002:a7b:c416:0:b0:3ab:73e4:c44a with SMTP id k22-20020a7bc416000000b003ab73e4c44amr14182wmi.147.1662579407440; Wed, 07 Sep 2022 12:36:47 -0700 (PDT) MIME-Version: 1.0 From: Javier Steinaker Date: Thu, 8 Sep 2022 05:36:34 +1000 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000fdd04705e81b6eb3" Subject: [musl] strptime_l implementation --000000000000fdd04705e81b6eb3 Content-Type: text/plain; charset="UTF-8" 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. Thanks in advance, Javier --000000000000fdd04705e81b6eb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everybody,

The Haiku project (an alternative OS) switched to using musl a few weeks ag= o. 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 a= lways 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 diff= icult to move the current code to an internal function, and then have strpt= ime 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 i= t 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 ver= sion if it was useful here. Otherwise, we will just find our way in the Hai= ku code, via implementing strptime_l or with another solution.

Thanks in advance,
Javier
--000000000000fdd04705e81b6eb3--