为什么 gcc（或 glibc）没有实现 _s 函数？

Question

_s 函数，例如scanf_s ， printf_s似乎是可选标准。 MSVC 已经实现了这些功能，但是 gcc 没有。

不实现安全功能是否有具体原因？ glibc 的scanf是否足够安全？

Answer 1

_s函数是可选的（ C11 标准的附件 K ）。 它们被广泛认为“不是很有益”。

在我的问题的答案中，您是否使用 TR-24731“安全”功能？ ，您可以找到有关标准规范哪里存在问题的信息，例如标准和 Microsoft 实现之间的关键差异。 TR 24731-1 是 C 标准委员会的技术报告。 该报告几乎是逐字逐句地合并到 C11 标准中作为（可选但“规范性”）附件 K 中的一个额外的以前省略的功能 IIRC。还有用于不同功能集的 TR 24731-2 - 没有_s后缀. 由于一系列不同的原因，它遇到了阻力。

此外， C 标准委员会提出了一项建议，即在标准的下一次修订中删除这些功能：

• N1967附件 K 现场经验 — 边界检查接口

那篇论文是对 TR-24731 ( *_s() ) 函数没有被广泛实现的原因的直接而引人注目的阅读。

主要原因包括：

• 问题只被发现一次，然后修复，然后*_s()函数是不必要的。
• 这使得测试*_s()函数或使用它们的代码变得非常困难。
• 将新功能集成到旧代码中并不容易（这是最大的好处）。
• 这些功能固有地通过广泛但冗余的检查减慢了软件的速度。

有关更多详细信息，请参阅论文。 论文以以下部分结束：

建议的技术勘误表

尽管自最初的提案以来已有十多年的时间，并且自 ISO/IEC TR 24731-1:2007 批准以来已近十年，并且自将边界检查接口引入 C 标准以来已近五年，但没有出现可行的符合性实现. API 继续存在争议，实施者继续拒绝实施请求。

边界检查接口的设计虽然是善意的，但有太多的问题需要纠正。 与依赖既定方法或现代技术相比，使用 API 已被视为导致质量更差、安全性更低的软件。 更有效和更少侵入性的方法已变得司空见惯，并且通常受到用户和安全专家等人的青睐。

因此，我们建议附件 K 要么从 C 标准的下一个修订版中删除，要么弃用然后删除。