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.
2. macOS and the BSDs have localeconv_l(loc). FreeBSD's man page says:
RETURN VALUES
The localeconv() function returns a pointer to a static object which may
be altered by later calls to setlocale(3) or localeconv(). The return
value for localeconv_l() is stored with the locale. It will remain valid
until a subsequent call to freelocale(3). If a thread-local locale is in
effect then the return value from localeconv() will remain valid until
the locale is destroyed.
I suspect it would be impractical to propose any change to
localeconv() itself, given existing implementation techniques on
various existing systems including "it's just one static buffer".
But localeconv_l() seems to be a very straightforward idea that fits
into the general pattern of _l() functions. I suspect that the
standard might prefer to use wording similar to the treatment of
nl_langinfo_l()'s return value, offering more latitude to implementers
(including "it's just one static buffer per thread"), while still
making it plausible for a multi-threaded program to open a locale and
copy the lconv fields it needs somewhere else.
I see that "more _l function" proposals have been rejected:
https://austingroupbugs.net/view.php?id=1004
https://austingroupbugs.net/view.php?id=1049
So I would be grateful for any advice on how to go about proposing one
more successfully, along with any feedback on the relative merits of
the two approaches shown above, and any other ways this problem might
be attacked.
Thanks for reading,
Thomas Munro
