Martin Storsjö <[email protected]> wrote:
> On Mon, 6 Jul 2026, Kirill Makurin wrote:
>
>> Currently, we expose `_create_locale`, `_free_locale` and
>> `_get_current_locale` unconditionally.
>>
>> For msvcrt.dll, we provide wrappers which check their presence at
>> runtime, and replace them with simple stubs if they are not available.
>> Original commit[1] which added wrapper for `_get_current_locale` states
>> that it was added to allow building libc++ with msvcrt.dll, or at least
>> this is my understanding.
>>
>> In my previous replies I expressed my opinion that we eventually should
>> fix this and expose them only when _WIN32_WINNT set to 0x0602 or higher.
>> In the meantime, we can continue always exposing them with msvcrt.dll,
>> so project like libc++ continue building as expected.
>
> I don't see the urgency of doing this, really.

We cannot do it right now anyway, because it would break libc++ builds.

> Like a million other functions, that only are present in some newer
> version of msvcrt.dll, we expose the declarations unconditionally, and we
> statically link in a helper function that checks with GetProcAddress if
> the function is available, and uses it if it is available, otherwise use a
> (potentially non-functional) dummy replacement function.

In many cases, the emulation is actually functional; you can run `git grep 
"msvcrt_or_emu_glue.h"` to see functions for which such emulation is used 
(there may be more, though), and in most cases, emulation provides very 
reasonable behavior.

> Why do you feel the need to remove these, specifically, compared with
> other functions that are runtime loaded?

In contrast to other functions with such wrapper, we cannot really implement 
these `_locale_t` functions, other than always returning `NULL` as if they 
failed.

My expectation is that if an application or library uses `_locale_t`, it really 
depends on this CRT feature for one reason or another. However, in msvcrt.dll 
it is only fully available since Windows 8, making such applications and 
libraries half- or completely unfunctional on Windows 7 and older.

If we cannot provide functional emulation for some CRT function, I think it is 
better to make such application directly import such functions from msvcrt.dll, 
so instead of malfunctioning at runtime, they would simply not load.

- Kirill Makurin

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to