为什么 gcc(或 glibc)没有实现 _s 函数? [英] Why didn't gcc (or glibc) implement _s functions?

问题描述

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

_s functions, such as scanf_s, printf_s seems to be optional standard. MSVC has implemented these functions, but gcc hasn't.

未实现安全功能是否有特定原因?glibc的scanf是否足够安全?

Is there specific reason for not implementing secure functions? Is scanf of glibc secure enough?

推荐答案

_s 函数是可选的 (C11 标准的附录 K).他们被广泛认为不太有益".

The _s functions are optional (Annex K of the C11 standard). They're widely regarded as 'not very beneficial'.

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

In the answers to my question Do you use the TR-24731 "safe" functions?, you can find information about where there are problems with the standard specification — such as crucial differences between the standard and Microsoft's implementation. TR 24731-1 was a technical report from the C standard committee. The report was incorporated almost verbatim — with an extra, previously omitted, function, IIRC — in the C11 standard as (optional but 'normative') Annex K. There's also TR 24731-2 for a different set of functions — without the _s suffix. It ran into resistance for a different set of reasons.

此外，在 C 标准委员会之前有一项提议，即从标准的下一个版本中删除功能:

Also, there is a proposal before the C Standard Committee that the functions be removed from the next revision of the standard:

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

那篇论文是对 TR-24731 (*_s()) 函数未得到广泛实施的原因的直接且令人信服的解读.

That paper is a straight-forward and compelling read of the reasons why the TR-24731 (*_s()) functions have not been widely implemented.

主要原因包括:

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

• The problem is only spotted once, then fixed, and then the *_s() function is unnecessary.
• This makes it very hard to test the *_s() functions, or the code which uses them.
• It isn't easy to integrate the new functions into old code (which is where there'd be most benefit).
• The functions inherently slow down software with extensive but redundant checking.

有关详细信息，请参阅论文.论文结尾部分:

See the paper for more details. The paper ends with the section:

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

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.

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

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.

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

Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed.

这篇关于为什么 gcc(或 glibc)没有实现 _s 函数?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！