* [musl] strptime_l implementation @ 2022-09-07 19:36 Javier Steinaker 2022-09-07 20:06 ` Markus Wichmann 2022-09-07 20:49 ` Rich Felker 0 siblings, 2 replies; 6+ messages in thread From: Javier Steinaker @ 2022-09-07 19:36 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1019 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 1185 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] strptime_l implementation 2022-09-07 19:36 [musl] strptime_l implementation Javier Steinaker @ 2022-09-07 20:06 ` Markus Wichmann 2022-09-07 20:49 ` Rich Felker 1 sibling, 0 replies; 6+ messages in thread From: Markus Wichmann @ 2022-09-07 20:06 UTC (permalink / raw) To: musl 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. > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] strptime_l implementation 2022-09-07 19:36 [musl] strptime_l implementation Javier Steinaker 2022-09-07 20:06 ` Markus Wichmann @ 2022-09-07 20:49 ` Rich Felker 2022-09-07 22:46 ` James Y Knight 1 sibling, 1 reply; 6+ messages in thread From: Rich Felker @ 2022-09-07 20:49 UTC (permalink / raw) To: Javier Steinaker; +Cc: musl 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] strptime_l implementation 2022-09-07 20:49 ` Rich Felker @ 2022-09-07 22:46 ` James Y Knight 2022-09-08 0:03 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: James Y Knight @ 2022-09-07 22:46 UTC (permalink / raw) To: musl; +Cc: Javier Steinaker [-- Attachment #1: Type: text/plain, Size: 2338 bytes --] 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 <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 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 > [-- Attachment #2: Type: text/html, Size: 2933 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] strptime_l implementation 2022-09-07 22:46 ` James Y Knight @ 2022-09-08 0:03 ` Rich Felker 2022-09-08 0:23 ` Javier Steinaker 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2022-09-08 0:03 UTC (permalink / raw) To: James Y Knight; +Cc: musl, Javier Steinaker 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 <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 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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] strptime_l implementation 2022-09-08 0:03 ` Rich Felker @ 2022-09-08 0:23 ` Javier Steinaker 0 siblings, 0 replies; 6+ messages in thread From: Javier Steinaker @ 2022-09-08 0:23 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 4613 bytes --] 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 <dalias@libc.org> escribió: > 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 <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 > 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 > > > > [-- Attachment #2: Type: text/html, Size: 5755 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-09-08 0:23 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-07 19:36 [musl] strptime_l implementation Javier Steinaker 2022-09-07 20:06 ` Markus Wichmann 2022-09-07 20:49 ` Rich Felker 2022-09-07 22:46 ` James Y Knight 2022-09-08 0:03 ` Rich Felker 2022-09-08 0:23 ` Javier Steinaker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).