I'm having trouble using strerrorlen_s in gcc 4.7.2 even though I defined __STDC_WANT_LIB_EXT1__ 1.
尽管我定义了__STDC_WANT_LIB_EXT1__，但在gcc 4.7.2中使用strerrorlen_s时遇到了麻烦。
2 个解决方案
#1
3
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.
它不是在glib 2.13中，至少在Debian中，但我不明白为什么它会和其他系统不同。对整个磁盘上的strerrorlen_s的搜索没有返回任何内容。
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.
它也没有在2.14通过当前的2.17(搜索范围，tr24731和strerrorlen_s)的发行说明中列出。在2.18 wiki页面上甚至没有提到。
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.
请记住，边界检查接口是C11的一个可选特性。附件K详细说明了这一点，而实现根本不需要提供。
K.2 Scope:
K.2范围:
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.2/一个定义__STDC_LIB_EXT1__的实现应符合本附件中的规范。不需要定义__STDC_LIB_EXT1__的实现不需要符合这些规范。
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:
实际上，在核心glibc上，实际上并没有计划来支持这个特性。来自Ulrich Drepper(2012年3月)关于是否会支持的评论:
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.
即使是那些提出建议的人也建议他们修改旧代码，而不是前进的方向。这样的代码属于单独的库，这些库(a)需要努力使用，以便函数不再使用(b)，这样当最后一个犯罪者离开时，库就可以被删除。
Similarly, from an LNW article around the same time:
同样，从LNW的文章也可以看到:
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.
目前还没有计划将C11字符串从其中一个附件中添加到检查接口中，因为在标准组中也存在关于它们有用性的问题。这并不意味着这些接口不能在libc_ports树中结束，它为可选的附加组件提供了一个位置，默认情况下是不启用的。这将允许发行版或其他版本在其版本的GLIBC中构建这些功能。
#2
0
N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x
errno_t strerror_s(char *s, rsize_t maxsize, errno_t errnum);
size_t strerrorlen_s(errno_t errnum);
size_t strnlen_s(const char *s, size_t maxsize);
That's from my copy of the C11 standard - draft N1570. Maybe later versions of gcc have it... So we are not both crazy....
这是我的C11标准草案N1570的复印件。可能以后版本的gcc有…所以我们不疯狂....
#1
3
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.
它不是在glib 2.13中，至少在Debian中，但我不明白为什么它会和其他系统不同。对整个磁盘上的strerrorlen_s的搜索没有返回任何内容。
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.
它也没有在2.14通过当前的2.17(搜索范围，tr24731和strerrorlen_s)的发行说明中列出。在2.18 wiki页面上甚至没有提到。
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.
请记住，边界检查接口是C11的一个可选特性。附件K详细说明了这一点，而实现根本不需要提供。
K.2 Scope:
K.2范围:
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.2/一个定义__STDC_LIB_EXT1__的实现应符合本附件中的规范。不需要定义__STDC_LIB_EXT1__的实现不需要符合这些规范。
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:
实际上，在核心glibc上，实际上并没有计划来支持这个特性。来自Ulrich Drepper(2012年3月)关于是否会支持的评论:
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.
即使是那些提出建议的人也建议他们修改旧代码，而不是前进的方向。这样的代码属于单独的库，这些库(a)需要努力使用，以便函数不再使用(b)，这样当最后一个犯罪者离开时，库就可以被删除。
Similarly, from an LNW article around the same time:
同样，从LNW的文章也可以看到:
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.
目前还没有计划将C11字符串从其中一个附件中添加到检查接口中，因为在标准组中也存在关于它们有用性的问题。这并不意味着这些接口不能在libc_ports树中结束，它为可选的附加组件提供了一个位置，默认情况下是不启用的。这将允许发行版或其他版本在其版本的GLIBC中构建这些功能。
#2
0
N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x
errno_t strerror_s(char *s, rsize_t maxsize, errno_t errnum);
size_t strerrorlen_s(errno_t errnum);
size_t strnlen_s(const char *s, size_t maxsize);
That's from my copy of the C11 standard - draft N1570. Maybe later versions of gcc have it... So we are not both crazy....
这是我的C11标准草案N1570的复印件。可能以后版本的gcc有…所以我们不疯狂....