ISO C委员会(ISO/IEC JTC1/SC21/WG14)出版了TR 24731-1本，目前正在研究TR 24731-2本:
TR 24731-1:C库扩展，第一部分:边界判断接口
WG14正在开发一个关于更安全的C库函数的TR.该TR面向修改现有程序，通常通过添加一个带有缓冲区长度的额外参数.最新草案见文件N1225.基本原理见文件N1173.这将成为技术报告类型2.
TR 24731-2:C库的扩展-第二部分:动态分配功能
WG14正在开发一个关于更安全的C库函数的TR.该TR面向使用动态分配的新程序，而不是缓冲区长度的额外参数.最新草案见N1337号文件.这将成为技术报告类型2.
从一开始(当它是一个单一的TR时)，我就一直是这些TR的直言不讳的批评者，并且永远不会在我的任何软件中使用它们.它们掩盖了症状，而不是解决了问题的原因.我认为，如果有什么问题的话，它们将对软件设计产生负面影响，因为它们提供了错误的安全感，而不是推广可以更有效地实现相同目标的现有实践.并非只有我一人，事实上，我不知道委员会之外有哪一位主要支持者在开发这些TRs.
我使用glibc，因此我知道我将不用处理这些废话，正如glibc的首席维护人员Ulrich Drepper，said about the topic:
建议的SAFE(R)ISO C库 未能完全解决问题. ...提议让一个人的生活 程序员即使更努力也不会 帮助.但这就是事实 建议....他们都要求更多 要做的工作或只是简单的工作 太傻了.
他接着详述了一些拟议功能的问题，并在其他地方表示，glibc永远不会支持这一点.
奥斯汀小组(负责维护POSIX)对TR、他们的意见和委员会现有的答复进行了非常严格的审查here.Austin Group的审查做了非常好的工作，详细描述了TR的许多问题，所以我不会在这里深入讨论个别细节.
所以底线是:我不使用支持或将支持这个功能的实现，我不打算使用这些功能，我个人认为，TR仍然以任何形式存在的唯一原因是，微软正在大力推动TR，尽管存在广泛的反对意见，但最近证明微软非常有能力通过标准委员会对其进行抨击.如果这些功能被标准化，我不认为它们会被广泛使用，因为该提案已经存在了几年，并且没有获得任何真正的社区支持.