C11 defined the optional secure extensions to be demanded by __STDC_WANT_LIB_EXT1__.

From the following tested libc implementations:

glibc
musl
FreeBSD and DragonFly libc
FreeBSD-derived darwin libc
OpenBSD libc
newlib (Cygwin)
dietlibc
uClibc
minilibc
Microsoft Windows under wine
Microsoft Windows msvcrt and ulibc w/ secure API
Open Watcom
Android Bionic
Huawei securec
Embarcadero C++ libc
slibc

only the last 6 implement the secure C11 extensions:

Microsoft Windows
Open Watcom since 1.5
Android Bionic w/ stlport
Huawei securec
Embarcadero C++ libc
slibc

General quirks

Generally most libc's use a 4 byte wchar_t (which resembles UTF-32), but windows/cygwin/solaris/aix use 2-byte (UTF-16), therefore they need to support surrogate pairs.

The wide sprintf variants do not allow a NULL buffer argument to return the size of the resulting buffer. If the initial buffer is too small, you need to realloc and redo.

There's still no locale-independent utf8 support, not even in C11 with its new u8"" type.

Many wchar and mb conversions and searches are locale-dependent, hence unusable for utf8.

Nobody implements a proper wchar case-conversion, foldcase and normalization API. ICU or libunistring are way too heavy for this simple problem. There's only utf8proc for utf8 encoded strings (now with julia).

None of the other libc's (and neither most crypto libraries) provide a secure memory barrier for memset/memzero/memset_s/explicit_bzero/SecureZeroMemory/..., they only provide a compiler barrier against false compiler optimizations. They don't reliably sync memory stores with possibly re-ordered loads by modern out-of-order CPU's. Only the linux kernel and safeclib do so.

C11 Annex K/safec caveats

tmpnam_s:

Is considered unsafe. tmpnam_s and tmpnam are racy.
sprintf_s and vsprintf_s retval on errors.

They were revised by the author from Microsoft in n1141 to return 0 on most errors (only -1 on encoding errors), to allow the often used count += sprintf(buf + count, format_string, args); when no encoding errors could occur, ignoring retval < 0 checks. Lateron Microsoft and all other implementors (e.g. Embacadero, safeclib) revised this decision to be consistent, to return -1 on all errors, just the standard still contains the n1141 revision.

Microsoft Windows/MINGW_HAS_SECURE_API

fopen_s, freopen_s deviate in the API: restrict is missing.
strtok_s, wcstok_s,vsnprintf_s miss the dmax argument.
vsnprintf_s adds a maxarg argument.
vswprintf adds a maxarg argument on w32. (with __STRICT_ANSI__ undefined)
no strnlen on mingw32.
no errno_t return type for qsort_s, only void.
reversed argument order for localtime_s and gmtime_s.
older mingw versions have wchar.h with only 2 functions: wcscmp, wcslen
no RSIZE_MAX
memmove_s does not clear dest with ERANGE when count > dmax and EINVAL when src is a NULL pointer.
vsprintf_s, sprintf_s return -1 on all errors, not just encoding errors. (Wrong standard)
With wcsrtombs (used by wcsrtomb_s) the *retval result includes the terminating zero, i.e. the result is +1 from the spec.
getenv_s returns in len the size of the env buffer, not the len, as described in the standard (https://en.cppreference.com/w/c/program/getenv). The Microsoft size is len + 1. Their usage example is also wrong: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/getenv-s-wgetenv-s?view=msvc-170

safeclib

safeclib does not check optional NULL parameters to the vararg scanf_s and printf_s functions. This would need tighter integration into the upstream libc. Similarily the 2nd size parameter for s, c and %[ is not implemented.
safeclib fgets_s permits temporary writes of dmax+1 characters into dest.
vsprintf_s, sprintf_s return -1 on all errors, not just encoding errors. (Wrong standard)

Android FORTIFY and _STLP_USE_SAFE_STRING_FUNCTIONS

Not yet tested. Hard to find as open source. Apparently once implemented as part of the stlport library, but unused and I cannot find it in Bionic (orea), which is mostly an improved FreeBSD libc. stlport had a portable rewrite of the secure Windows API, written in 1999. Now they use just the fortified POSIX API, e.g. for strncpy_s strncpy_chk and __strncpy_chk2 with known src size.

See Wikipedia: Bionic Fortify_source, and their blog post FORTIFY in Android.

Basically they use a __bos() or __builtin_object_size macro which is a better sizeof and expands to the size of the compile-time pointer when the size of the buffer is known at compile-time. They also try to use the alloc_size extension which looks at a malloc'ed pointer into the previous word for its size. So there's no secure API, just the normal POSIX and glibc API with compile-time _chk checks as in glibc with FORTIFY. Just a bit better than glibc.

Huawei securec

This is similar to the secure Android and slibc variant, written in C and it is a proper secure libc. Their license is restrictive though: Copyright @ Huawei Technologies Co., Ltd. 1998-2014. All rights reserved.

Available at https://github.com/UVP-Tools/UVP-Tools/tree/master/uvp-monitor/securec There are other variants under the GPL-2 and Apache 2.0 on github (e.g. wangguitao/intelligent-protector)

Open Watcom 1.5

Tested by http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm#alternatives It sets the __STDC_LIB_EXT1__ macro to 200509L and can be considered a nearly conforming implementation.

slibc

"Slibc is a complete, open source implementation of Annex K designed to be used with GNU C library typically distributed with Linux. The implementation claims to be complete and to fully conform to C11. An inspection of the implementation reveals that it is quite inefficient and thus unsuitable for production use without considerable changes. It does provide a good referefence implementation of the library. A proposal to incorporate slibc into the GNU C library was submitted in 2012 to the GNU C library community and rejected."

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm#alternatives

Available at https://code.google.com/archive/p/slibc/

Other caveats

glibc

SEGV with freopen(NULL, "rb", stdin) with asan on some systems, calling an invalid strlen() on NULL.
quirky declaration of various standards, which conflict with each other.

glibc needs the correct standard to include some extensions when we declare the standard by ourselves. e.g. clang-4.0 -std=c99 misses several reentrant versions. when defining _XOPEN_SOURCE 700 to define strnlen and the reentrant time versions, we need also __STDC_WANT_LIB_EXT1__ 1 for errno_t, and this would break several other older struct members, such as tm_gmtoff

newlib

vswscanf is broken with a format string containing L"%%n"
The following multibyte API's are missing, and can be defined like this:

mbstate_t st;
#define wctomb(dest, wc) wcrtomb((dest), (wc), &st)
#define wcstombs(dest, src, len) wcsrtombs((dest), &(src), (len), &st)
#define mbstowcs(dest, src, len) mbsrtowcs((dest), &(src), (len), &st)

FreeBSD libc

vswscanf is broken with a format string containing L"%%n"
mbstowcs is broken with ‘(NULL, ’\0')`

musl

wmemcmp returns not -1, 0 or 1 but the full ptr diff.
mbtowc and wctomb accept and convert illegal 4 byte characters in the ASCII locale to surrogate pairs, as it would be unicode. e.g. it converts \xa0 to \xdfa0.

wine

As of wine-2.0.4 its libc has several more errors than the msvcrt sec_api:

asctime_s with tm->mday=0 returns not EINVAL but 0.
wcsncat_s(dest, dmax, src, 0) returns not EINVAL but 0.
wcsncat_s(NULL, 0, src, 0); returns not 0 but EINVAL.
more wcsncat_s: ESUNTERM and ESOVRLP do not clear dest
wcsrtombs_s(&ind, dest, 0, &cs, 0, &ps) returns not EINVAL but 0, with ind kept at 0.

It's now 10 years after the secure libc extensions were designed, C11 adopted them, and still almost nobody implements them. Only for compile-time known sizes the FORTIFY _chk extension secures against overflows, but not against dynamically allocated buffers. This library was written 2008 under the MIT license, thanks Cisco.

Reini Urban 2018