ISO C委员会（ISO/IEC JTC1/SC21/WG14）已发布TR 24731-1并正在制作TR 24731-2：
TR 24731-1：C库的扩展第一部分：界限检查接口
WG14正在研究更安全的C库函数。该TR旨在通过添加具有缓冲区长度的额外参数来修改现有程序。最新草案见N1225号文件。理由是在N1173号文件中。这将成为技术报告类型2.
TR 24731-2：C库的扩展 - 第二部分：动态分配函数
WG14正在研究更安全的C库函数。该TR面向使用动态分配而不是缓冲区长度的额外参数的新程序。最新草案见N1337号文件。这将成为技术报告类型2.
答案 0 :(得分：64)
自从他们成立以来（当它是一个TR）时，我一直是这些TR的声音批评者，并且永远不会在我的任何软件中使用它们。它们掩盖症状而不是解决原因，我认为，如果有的话，它们会对软件设计产生负面影响，因为它们提供了错误的安全感，而不是促进可以更有效地实现相同目标的现有实践。我并不孤单，事实上我并不知道在委员会之外发展这些TR的一个主要支持者。
我使用glibc并且因此知道我将不得不处理这个废话，正如glibc的主要维护者Ulrich Drepper，said about the topic：
建议的安全（r）ISO C库 未能完全解决问题。 ......提议创造一个人的生命 程序员更难是不会 救命。但这正是如此 建议。 ......他们都需要更多 工作要做或者很简单 愚蠢的。
他接着详细介绍了许多拟议函数的问题，并在其他地方表示glibc永远不会支持这一点。
奥斯汀集团（负责维护POSIX）对TR提供了非常严格的审查，他们的评论和委员会的回复here。奥斯汀集团的审查工作非常好，详细说明了TR的许多问题，所以我不会在这里详细介绍。
所以底线是：我没有使用支持或支持这个的实现，我不打算永远使用这些功能，我看不到TR的正面价值。我个人认为，TR仍然以任何形式存在的唯一原因是因为它受到了微软的推动，最近证明尽管有广泛的反对意见，尽管标准委员会已经将事情弄得一团糟。如果这些功能一直标准化，我认为它们不会被广泛使用，因为该提案已经存在了几年，并且未能获得任何真正的社区支持。
答案 1 :(得分：28)
答案 2 :(得分：7)
好的，现在是 TR24731-2的展位
是的，自从我在glibc中看到它们以来，我一直使用asprintf() / vasprintf()，是的，我是他们的坚定拥护者。
为什么呢？ 因为它们能够一次又一次地提供我需要的功能：一种功能强大，灵活，安全且（相对）易于使用的方式，可以将任何文本格式化为新分配的字符串。
我也非常支持memstream：像asprintf()，open_memstream()（不是fmemopen() !!!）为你分配一个足够大的缓冲区并给你一个{{1你的打印功能，你的打印功能完全不知道它们是打印成字符串还是文件，你可以简单地忘记问题，你需要多少空间。
答案 3 :(得分：5)
您是否使用支持TR24731-1功能的库或编译器？ 如果是这样，哪个编译器或库以及哪个平台？
是的，Visual Studio 2005＆amp; 2008（显然是Win32开发）。
您是否因修复代码以使用这些功能而发现任何错误？
排序....我编写了自己的安全功能库（我们经常使用的只有15个），可以在多个平台上使用 - Linux，Windows，VxWorks，INtime，RTX和uItron。创建安全功能的原因是：
编写函数后，发现了更多错误。所以是的，使用函数是有价值的。
哪些功能提供最大价值？
更安全的vsnprintf版本，strncpy，strncat。
有没有提供任何价值或负值？
fopen_s和类似的功能对我个人来说几乎没有什么价值。如果fopen返回NULL，我很好。您应该始终检查函数的返回值。如果有人忽略了fopen的返回值，那么是什么让他们检查fopen_s的返回值？我知道fopen_s将返回更具体的错误信息，这些信息在某些情况下很有用。但是对于我正在做的事情，这没关系。
您打算将来使用该库吗？
我们现在正在使用它 - 在我们自己的“安全”库中。
您是否正在跟踪TR24731-2的工作？
没有
答案 4 :(得分：5)
不，这些功能绝对无用，除了鼓励编写代码以外它没有任何用途，因此它只能在Windows上编译。
snprintf非常安全（正确实现时），因此snprintf_s毫无意义。如果缓冲区溢出（通过清除连接到字符串），strcat_s将销毁数据。还有许多其他例子完全忽略了事情的运作方式。
真正有用的功能是BSD strlcpy和strlcat。但是，微软和Drepper都出于自私的原因拒绝了这些，以及各地C程序员的烦恼。