为什么 gcc（或 glibc）不实现 _s 函数？
Why didn't gcc (or glibc) implement _s functions?
_s函数，比如scanf_s，printf_s好像是可选标准。 MSVC已经实现了这些功能，但是gcc还没有。
是否有没有实现安全功能的具体原因？ scanf glibc 是否足够安全？
_s 函数是可选的 (Annex K of the C11 standard)。他们被广泛认为是 'not very beneficial'.
在我的问题 Do you use the TR-24731 "safe" functions? 的答案中，您可以找到有关标准规范哪里存在问题的信息，例如标准与 Microsoft 实施之间的关键差异。 TR 24731-1 是 C 标准委员会的技术报告。该报告几乎一字不差地合并到 C11 标准中作为（可选但 'normative'）附件 K 中的一个额外的，以前省略的函数 IIRC。还有 TR 24731-2 用于一组不同的函数 - 没有_s 后缀。它 运行 由于一系列不同的原因而陷入阻力。
此外，在 C Standard Committee 之前有一个提议，即从标准的下一次修订中删除这些功能：
该论文直截了当且引人入胜，解释了 TR-24731 (*_s()) 功能未得到广泛实施的原因。
主要原因包括：
- 这个问题只发现一次，然后就修复了，然后
*_s() 功能就不需要了。
- 这使得测试
*_s() 函数或使用它们的代码变得非常困难。
- 将新功能集成到旧代码中并不容易（这是最有好处的地方）。
- 这些函数通过广泛但冗余的检查本质上会减慢软件速度。
有关详细信息，请参阅论文。论文结尾部分：
Suggested Technical Corrigendum
Despite more than a decade since the original proposal and nearly ten years since the ratification of ISO/IEC TR 24731-1:2007, and almost five years since the introduction of the Bounds checking interfaces into the C standard, no viable conforming implementations has emerged. The APIs continue to be controversial and requests for implementation continue to be rejected by implementers.
The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. More effective and less intrusive approaches have become commonplace and are often preferred by users and security experts alike.
Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed.
附件 K 未从 C17 中删除。标准委员会 (ISO JTC1/SC22/WG14) 的两篇新论文讨论了附件 K:
_s函数，比如scanf_s，printf_s好像是可选标准。 MSVC已经实现了这些功能，但是gcc还没有。
是否有没有实现安全功能的具体原因？ scanf glibc 是否足够安全？
_s 函数是可选的 (Annex K of the C11 standard)。他们被广泛认为是 'not very beneficial'.
在我的问题 Do you use the TR-24731 "safe" functions? 的答案中，您可以找到有关标准规范哪里存在问题的信息，例如标准与 Microsoft 实施之间的关键差异。 TR 24731-1 是 C 标准委员会的技术报告。该报告几乎一字不差地合并到 C11 标准中作为（可选但 'normative'）附件 K 中的一个额外的，以前省略的函数 IIRC。还有 TR 24731-2 用于一组不同的函数 - 没有_s 后缀。它 运行 由于一系列不同的原因而陷入阻力。
此外，在 C Standard Committee 之前有一个提议，即从标准的下一次修订中删除这些功能：
该论文直截了当且引人入胜，解释了 TR-24731 (*_s()) 功能未得到广泛实施的原因。
主要原因包括：
- 这个问题只发现一次，然后就修复了，然后
*_s()功能就不需要了。 - 这使得测试
*_s()函数或使用它们的代码变得非常困难。 - 将新功能集成到旧代码中并不容易（这是最有好处的地方）。
- 这些函数通过广泛但冗余的检查本质上会减慢软件速度。
有关详细信息，请参阅论文。论文结尾部分：
Suggested Technical Corrigendum
Despite more than a decade since the original proposal and nearly ten years since the ratification of ISO/IEC TR 24731-1:2007, and almost five years since the introduction of the Bounds checking interfaces into the C standard, no viable conforming implementations has emerged. The APIs continue to be controversial and requests for implementation continue to be rejected by implementers.
The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. More effective and less intrusive approaches have become commonplace and are often preferred by users and security experts alike.
Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed.
附件 K 未从 C17 中删除。标准委员会 (ISO JTC1/SC22/WG14) 的两篇新论文讨论了附件 K: