为什么gcc没有实现_s函数？

Question

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

是否有特定原因未实施安全功能？ gcc的scanf足够安全吗？

Answer 1

_s函数是可选的（Annex K of the C11 standard）。他们被广泛认为“不是非常有益”。

在我的问题Do you use the TR-24731 "safe" functions?的答案中，您可以找到有关标准规范存在问题的位置的信息 - 例如标准与Microsoft实施之间的重要差异。 TR 24731-1是C标准委员会的技术报告。该报告几乎是逐字记录的 - 在C11标准中有一个额外的，以前省略的功能，IIRC - （可选但“规范”附件K）。 TR 24731-2还有一组不同的功能 - 没有_s后缀。由于一系列不同的原因，它遇到了阻力。

此外，在C Standard Committee之前有一项提案，要求从标准的下一版本中删除这些功能：

• N1967 Field Experience with Annex K — Bounds Checking Interfaces

该论文直截了当地引用了TR-24731（*_s()）功能未被广泛实施的原因。

主要原因包括：

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

有关详细信息，请参阅该文章。本文以以下部分结束：

  

建议的技术勘误

     

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

     

Bounds检查界面的设计虽然用心良苦，但却存在太多难以纠正的问题。使用API​​已被视为导致质量更差，软件安全性低于依赖既定方法或现代技术。更有效和更少侵入性的方法已经变得司空见惯，并且通常受到用户和安全专家的青睐。

     

因此，我们建议将附件K从C标准的下一版本中删除，或者弃用然后删除。