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

Question

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

是否有不实施安全功能的具体原因？scanfglibc 足够安全吗？

Answer 1

这些_s功能是可选的（C11 标准的附录 K）。它们被广泛认为“不是很有益”。

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

此外，C 标准委员会还提议从标准的下一个修订版中删除这些功能：

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

*_s()该论文对 TR-24731 ( ) 功能尚未广泛实施的原因进行了直截了当且令人信服的解读。

主要原因包括：

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

有关详细信息，请参阅论文。本文以以下部分结尾：

建议的技术勘误

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

Bounds 检查接口的设计虽然是出于好意，但存在太多需要纠正的问题。与依赖现有方法或现代技术相比，使用 API 会导致软件质量更差、安全性更低。更有效且侵入性更小的方法已变得司空见惯，并且经常受到用户和安全专家的青睐。

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