Hi Bruno, Bruno Haible <br...@clisp.org> writes:
>> > const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE)); >> >> This is not thread-safe but I guess there’s no other choice. > > This code is only used on glibc systems, and nl_langinfo is multithread-safe > on glibc systems (by code inspection and due to the way it mmaps the locales). > This means, as long as no thread is calling setlocale, all threads can use > all locale functions in parallel without interference. If you call setlocale > while other threads are using locales, you are out for trouble anyway. OK, good to know. >> Presumably an ‘nl_langinfo_l’ module could build on the ‘duplocale’ >> module like this: [...] > Such code is better written to use uselocale(), which does normally not > cause memory allocation. Right. > You can define such a function for yourself; I agree with Ulrich, Jakub, and > Eric that this functionality should not be in POSIX and hence also not > necessarily in gnulib. Well, as we discussed, an interpretation of http://www.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html is that ‘LC_GLOBAL_LOCALE’ can be used anywhere a ‘locale_t’ is expected. Then again, I understand the performance concerns... Thanks, Ludo’.
