Martin Storsjö <[email protected]> wrote: > On Wed, 8 Jul 2026, Kirill Makurin wrote: > >> I agree with this in context of libc++, but what if some other project >> heavily relies on working `_create_locale`? > > In theory I could understand the argument, somehwat, but this is > exceedingly rare in real world code, as far as I've seen.
I think some gnulib modules can make use of `_locale_t` if working `_create_locale` is detected during configuration. I'm not sure if important packages like libiconv or gettext (libintl, gettext-tools) make use of `_locale_t`. >> I think that the perfect solution would be for libc++ to check whether >> `_create_locale` is really available during configuration. However, you >> pointed out that getting this done in libc++ would be troublesome. >> >> In another reply I suggested to expose `_create_locale` etc. for >> msvcrt.dll with _WIN32_WINNT defined to 0x0601 (Vista) or higher; this >> will expose them when other `_locale_t` functions are also exposed (they >> are available in msvcrt.dll since Vista). > > Exposing it only from Vista, which shouldn't require any changes to the > libc++ build, sounds tolerable to me. I can prepare updated version of changes; in current version it is exposed for msvcrt.dll unconditionally, though. The only question left is whether it is ok to add corecrt_wlocale.h (to de-duplicate declarations in locale.h and wchar.h), which does not exist in MSVC. - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
