为什么gcc(或glibc)没有实现_s函数?

utugiqy6  于 2023-03-07  发布在  其他
关注(0)|答案(1)|浏览(153)

_s函数,如scanf_sprintf_s似乎是可选的标准,MSVC已经实现了这些函数,但gcc没有。
没有实现安全功能有什么具体原因吗?glibc的scanf是否足够安全?

dsf9zpds

dsf9zpds1#

_s函数是可选的(C11标准的附录K),它们被广泛认为"不是很有用"。
在对我的问题Do you use the TR-24731 "safe" functions?的回答中,您可以找到有关标准规范哪里存在问题的信息--比如标准和微软实现之间的关键差异。TR 24731 - 1是来自C标准委员会的技术报告。该报告几乎逐字纳入--带有一个额外的、以前省略的函数,memset_s()-在C11标准中作为(可选但"规范性")附录K。还有TR 24731 - 2用于一组不同的功能-没有_s后缀。由于一组不同的原因,它遇到了阻力。
此外,在C Standard Committee之前有一个提议,即附录K中定义的功能应从标准的下一个修订版中删除:

这篇文章是对TR-24731(*_s())函数没有被广泛实现的原因的一个直接而令人信服的阅读。
主要原因包括:

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

更多细节请参见本文。本文结尾部分为:

建议的技术勘误表

尽管最初的提议已经提出了十多年,ISO/IEC TR 24731 - 1:2007已经批准了近十年,边界检查接口引入C标准也已经有近五年了,但仍然没有可行的符合标准的实现出现。API仍然存在争议,实现请求仍然被实现者拒绝。
边界检查接口的设计虽然初衷良好,但存在太多问题需要纠正。与依赖现有方法或现代技术相比,使用API会导致质量更差、安全性更低的软件。更有效、侵入性更低的方法已变得普遍,通常是用户和安全Maven的首选。
因此,我们建议从C标准的下一个修订版中删除附录K,或者先弃用再删除。
附录K未从C17中删除。标准委员会(ISO JTC1/SC22/WG14)的两份新文件讨论了附录K(并支持保留功能):

2023 - 03 - 05:看起来C23将保留附录K作为标准的可选部分。然而,有一个新函数memset_explicit(),它做memset_s()做的工作-优化器不允许跳过代码,即使变量集没有再次使用。

void *memset_explicit(void *s, int c, size_t n);
    • 说明**

2 memset_explicit函数复制c的值(将unsigned char转换为s指向的对象的每个前n字符。此函数的目的是使存储在对象中的敏感信息不可访问380)。
380)这样做的目的是不管优化如何,内存存储总是被执行(即永远不会被取消),这与memset函数的调用(7.26.6.1)形成了对比。

相关问题