I'm having trouble using strerrorlen_s in gcc 4.7.2 even though I defined __STDC_WANT_LIB_EXT1__ 1.
It's not in glib 2.13, at least under Debian, but I can't see why that would be different to any other system. A search for strerrorlen_s on the whole disk returns nothing.
It's also not listed in any of the release notes for 2.14 through the current 2.17 (searched for bounds, tr24731 and strerrorlen_s). It's not even mentioned on the 2.18 wiki page.
Keep in mind that the bounds checking interfaces are an optional feature of C11. Annex K details this, and implementations are not required to provide it at all.
K.2 Scope:
1/ This annex specifies a series of optional extensions that can be useful in the mitigation of security vulnerabilities in programs, and comprise new functions, macros, and types declared or defined in existing standard headers.
2/ An implementation that defines
__STDC_LIB_EXT1__shall conform to the specifications in this annex. Implementations that do not define__STDC_LIB_EXT1__are not required to conform to these specifications.
It looks like there are actually no plans to support this feature in the core glibc at all. From a comment by Ulrich Drepper (admittedly March 2012) on whether support would be forthcoming:
Even the people who proposed them suggested them for fixing old code and not as the way forward. Such code belong in separate libraries which (a) take effort to use so that the functions become unused and (b) so that the library can be removed when the last offender is gone.
Similarly, from an LNW article around the same time:
There are no plans to add the C11 string bounds-checking interfaces from one of the annexes as there are questions about their usefulness even within the standards groups. That doesn't mean that those interfaces couldn't end up in the libc_ports tree, which provides a place for optional add-ons that aren't enabled by default. That would allow distributions or others to build those functions into their version of GLIBC.