Standard Library Modules: Transition away from OS-33790456 by davidmrdavid · Pull Request #5805 · microsoft/STL (original) (raw)

Re-creation of: #5660

As reported in devcomm 1126857, several UCRT functions are declared as static inline, especially those in time.h.

This non-conforming signature prevents us from naively exporting those functions via modules. We have workarounds for this, but they're imperfect.

Thankfully, the October 2025 Windows SDK release (v10.0.26100.6901) improves on this issue.
It exposes a new binary macro _STATIC_INLINE_UCRT_FUNCTIONS . When set to 0, the functions will have 'external linkage' (conforming behavior, compatible with modules) and when set to 1, the functions will have static linkage for backwards compatibility.

For MSC_VER_ >= 1950, _STATIC_INLINE_UCRT_FUNCTIONS will default to 0. Otherwise, it'll default to 1.

This PR consumes the new macro and uses its value to determine whether or not to use our workarounds when building the std module.

Testing

I sense it's probably not worth it to add an automated test for this, but I'm open to be shown otherwise.

I have performed 2 local tests

(1)
In the STL repo, I manually added to the tests\std\tests\modules_20_matrix.lst the following diff:

diff --git a/tests/std/tests/modules_20_matrix.lst b/tests/std/tests/modules_20_matrix.lst
index 6ccb872f..d3d42a19 100644
--- a/tests/std/tests/modules_20_matrix.lst
+++ b/tests/std/tests/modules_20_matrix.lst
@@ -16,5 +16,8 @@ RUNALL_CROSSLIST
 *      PM_CL="/MDd /GR- /D_HAS_STATIC_RTTI=0"
 *      PM_CL="/MDd /utf-8"
 RUNALL_CROSSLIST
+*      PM_CL="/D_STATIC_INLINE_UCRT_FUNCTIONS=0"^M
+*      PM_CL="/D_STATIC_INLINE_UCRT_FUNCTIONS=1"^M
+RUNALL_CROSSLIST^M
 PM_CL=""
 ASAN   PM_CL="-fsanitize=address /Zi" PM_LINK="/debug"

Then I ran: python tests\utils\stl-lit\stl-lit.py ..\..\tests\std\tests\P2465R3_standard_library_modules

To my knowledge, that allows me to test all modules tests with the UCRT macro toggled on and off. In both cases, there's no regressions in STL functionality.

(2)

In an x64 native tools shell with the October '25 WIndows SDK installed, I tried manually exporting the affected UCRT functions in a module, like so:

C:\Users\dajusto\source\repros\ucrtscratch>type my_module.ixx
module;

// needed to access external linkage CRT functions before MSVC_VER 1950 is released.
#define _STATIC_INLINE_UCRT_FUNCTIONS 0

#include <corecrt_memcpy_s.h>
#include <corecrt_wstring.h>
#include <corecrt_wtime.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/timeb.h>
#include <sys/utime.h>
#include <time.h>

#include <vector>

export module time_module;

export using ::wcsnlen_s;
export using ::_wctime;
export using ::_wctime_s;
export using ::strnlen_s;
export using ::fstat;
export using ::stat;
export using ::ftime;
export using ::_utime;
export using ::_futime;
export using ::_wutime;
export using ::utime;
export using ::ctime;
export using ::difftime;
export using ::gmtime;
export using ::localtime;
export using ::_mkgmtime;
export using ::mktime;
export using ::time;
export using ::timespec_get;
export using ::ctime_s;
export using ::gmtime_s;
export using ::localtime_s;
C:\Users\dajusto\source\repros\ucrtscratch>cl /std:c++20 /c my_module.ixx /EHsc
Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35217 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

my_module.ixx

C:\Users\dajusto\source\repros\ucrtscratch>

As you can see, that worked.

This gives me confidence in the change. But again, I'm open to automated testing. Thanks!