Jonathan Wakely wrote, on 19 Aug 2024: > > On Mon, 19 Aug 2024 at 10:34, Geoff Clare via austin-group-l at The > Open Group <[email protected]> wrote: > > > > Jonathan Wakely wrote, on 19 Aug 2024: > > > > > > On Fri, 16 Aug 2024 at 10:37, Corinna Vinschen via austin-group-l at > > > The Open Group <[email protected]> wrote: > > > > > > > > On Aug 16 16:53, Thomas Munro via austin-group-l at The Open Group > > > > wrote: > > > > > Hello, > > > > > > > > > > I am aware of two thread-safe localeconv() alternatives in the wild: > > > > > > > > > > 1. glibc has nl_langinfo_l(DECIMAL_POINT, loc) for > > > > > localeconv()->decimal_point, and so on for every member of struct > > > > > lconv. > > > > > > > > nl_langinfo_l is also implemented in newlib and thus Cygwin since 2016. > > > > > > nl_langinfo_l is in POSIX, but glibc adds constants like DECIMAL_POINT > > > for all the lconv members. Those aren't required by POSIX, and don't > > > seem to be present in newlib. > > > > In glibc, DECIMAL_POINT is just a non-standard synonym for RADIXCHAR > > which is the langinfo.h constant POSIX requires for obtaining the decimal > > point character. It has a similar non-standard synonym for THOUSEP: > > Yes, and CURRENCY_SYMBOL is an alias for CRNCYSTR.
No, that's definitely not an alias. CURRENCY_SYMBOL gives you the lconv currency_symbol value. CRNCYSTR is different as it includes (limited) positioning info as well. If we end up adding constants for the lconv currency values, we should probably make CRNCYSTR obsolescent. > But Glibc also > provides several nl_item constants which are not synonyms of standard > ones, e.g. POSITIVE_SIGN, INT_FRAC_DIGITS, INT_P_SIGN_POSN etc. > > As Thomas said, this allows you to access every member of struct lconv > using nl_langinfo. Yes, I didn't mean to detract from your and Thomas's point about the extra constants where there is no POSIX equivalent. I only wanted to point out that two constants that might at first sight seem to be extras are not really new; they are just synonyms for standard constants. > The "redundant" synonyms like DECIMAL_POINT are > there for consistency, so you don't have to remember that > lconv::decimal_point must be accessed using RADIXCHAR instead of > DECIMAL_POINT. If we add the other constants, we should certainly consider adding DECIMAL_POINT and THOUSANDS_SEP as well, and maybe even making RADIXCHAR and THOUSEP obsolescent. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
