近期,这条由 C++ 创建者 Bjarne Stroustrup 与其它开发者联合发布声明表示,需要改变编程语言自身来解决解决安全问题。
“作为⼀种⾼性能的通⽤语⾔是 C++成功的原因。可能有⼀天 C++ 会将其⽕炬传递给另⼀种更强⼤的语⾔,但⽬前还不是这样。 我们永远不应该放弃数百万⾏现有代码,其中⼀些代码并不需要安全。我们应该认识到⽀持 C++ 安全的紧迫性是我们这个时代的问题之⼀。”Stroustrup 等人在文档里提到。他们总结了 C++ 的安全原则:
不要从根本上破坏向后兼容性——与更现代、更流行的语言相比,兼容性是 C++的一个关键特性和优势。
不要以无法表达抽象为代价来提供安全性,抽象是 C++力量的支柱。
不要留下一个“安全”的 C 子集,它会消除 C++的生产力优势。
具体来说,他们建议“将几个特性打包到配置文件中(Profiles )”(“配置文件”的解释是:定义要强制执行属性的限制和需求的集合,用来强制执⾏语义⼀致的规则集,⽽不是让单个开发⼈员在对单个语⾔、库设施和编码规则的⼤量限制中进⾏选择)。通过这种方式,安全方面的新更改“应该是可见的,这样安全代码部分就可以被命名(可能使用配置文件),并且可以与普通代码混合使用。
他们表示,配置文件专门用于支持嵌入式计算、性能敏感的应用程序,或高度特定的问题领域,如汽车、航空航天、航空电子设备、核或医疗应用程序。
“我们认为 Profiles 不会分裂⽣态系统,反⽽增加了多样性。”Stroustrup 等人表示。他们认为安全不应该强加于每个⼈,尤其是那些不需要或不想要的⼈。安全不应该是静态的,⽽是随着了解的增多、外部安全专家更好了解自己的真正需要后不断发展。
Stroustrup 这一举动的背后是近期美国国家安全局(NSA)等对 C++ 安全性的点名批评。但当时他对此表示否认:NSA 报告中提到的 “安全” 编程语言(如 C#、Rust、Go、Java、Ruby 或 Swift) 在重要应用程序中实际上并不优于 C++。
Stroustrup 当时批评 NSA 的报告只关注内存处理问题,而忽略了许多其他影响项目安全性和可靠性的编程语言问题。他建议使用代码注释和编译器选项来控制规则的包含,以确保类型和资源得到安全处理。考虑到可能对项目造成的破坏,他保证 C++ 社区不会忽视安全问题,但只关注安全问题也不行。
参考链接:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2759r0.pdf
推荐阅读:
评论 3 条评论