Missing C11 strerrorlen_s function under MSVC 2017

I'm trying to find which header to include for strerrorlen_s function from C11 standard under MSVC 2017. I need it for allocating space for error message which to get with strerror_s. The code is the following:

auto size = strerrorlen_s(errno) + 1;
char* errorReason = (char*)alloca(size);
strerror_s(errorReason, size, errno);
std::ostringstream oss;
oss << "Cannot open: " << fileName << " Reason: " << errorReason;
throw std::runtime_error(oss.str());

In the documentation are the following words:

As with all bounds-checked functions, strerror_s and strerrorlen_s are only guaranteed to be available if __STDC_LIB_EXT1__ is defined by the implementation and if the user defines __STDC_WANT_LIB_EXT1__ to the integer constant 1 before including string.h.

MSVC 2017 does not define __STDC_LIB_EXT1__ and it seems that defining __STDC_WANT_LIB_EXT1__ before including string.h doesn't have effect. Although strerror_s is available.

• Is strerrorlen_s available under Windows with MSVC 2017?
• Is it possible some other way to get error message length if the function is not available?
• Is strerror_s thread safe under Windows, because it seems that under Linux it's not and strerror_r must be used if there is need for thread safety, but it is not available on Windows?

Microsoft Visual Studio, when used as C compiler, mostly follows the 1990 version of the C standard. Some attempts have been made recently to update it to the 1999 version of the language. They are still far behind with that - the compiler is nowhere near the 2011 version. If you need a standard compliant C compiler you cannot use VS.

In addition, you seem to use the compiler in C++ mode which isn't exactly helping C standard compliance... C11 and C++11 are not always compatible.

That being said, the function you ask for is part of the optional bounds-checking interface, which I believe very few, if any, compilers have yet implemented. Some functions present in the bounds-checking interface existed in VS prior C11 as non-standard extensions. They are not necessarily standard compliant.

There are no guarantees that library functions are re-entrant. They may or may not be thread-safe.