为什么gcc没有实现_s函数? [英] Why didn't gcc 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.
是否存在不实施安全功能的特定原因? gcc的scanf是否足够安全?
Is there specific reason for not implementing secure functions? Is scanf of gcc secure enough?
推荐答案
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标准中，作为附加项(以前是省略的)IIRC，作为(可选，但是规范性的")附件K.还有TR 24731-2用于不同的功能集，而没有
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.
Bounds检查界面的设计虽然有很好的用意，但却有太多问题需要纠正.与依赖已建立的方法或现代技术相比，使用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没有实现_s函数?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
