内存安全要变天？C++创始人炮轰Rust舆论霸权

普及“内存安全语言”这事儿，近几年在美国科技界的推动下，已经写进了拜登的总统行政令成为“国策”。C和C++这对老牌编程语言，因为内存安全缺陷被宣判“死缓”，各行业和各国政府近年一直在喊话：别用C/C++了，换Rust、Go、C#、Java这些内存安全的“新宠”吧，DARPA甚至计划推出可自动将C语言代码转换为Rust语言代码的工具。

但是，随着拜登的“人走茶凉”，负责执行拜登网络安全政策CISA遭遇大裁员，阵脚大乱，C++的缔造者、哥伦比亚大学计算机科学教授Bjarne Stroustrup“觉得C++又行了”。Stroustrup近日公开发声，号召C++社区的广大程序员站出来为C++制造声势，反击“Rust派”的舆论霸权和攻击。

C和C++的麻烦，根源在于手动内存管理。程序员得自己分配和释放内存，一个不小心，就可能触发越界读写、缓冲区溢出这些“内存安全炸弹”。数据不会骗人：大型代码库中，70%的漏洞都和这些毛病脱不了干系。高危漏洞被黑客利用，造成的经济损失动辄数亿，C和C++自然成了众矢之的。

过去几年，欧美网络安全圈的态度很明确。美国网络安全与基础设施局（CISA）去年10月发布的《产品安全不良实践报告》直接点名：到2026年1月1日，用内存不安全语言（如C/C++）的制造商得拿出内存安全路线图，彻底消灭这类漏洞，或者干脆改用内存安全语言。微软Azure CTO Mark Russinovic++h早在2022年就放话：“别再用C/C++开新项目了，Rust才是正解。”Rust的拥趸们更是振臂高呼，称它天生内存安全，能从根儿上杜绝C++的“老毛病”。

面对这波“围剿”，C++社区也不是没反应。TrapC、FilC、Mini-C、Safe C++等一堆提案层出不穷，都想给C++补上内存安全的短板。但Stroustrup显然觉得，光靠技术补丁不够，还得在向Rust一边倒的舆论场上扳回一局。

2月7日，Stroustrup在给C++标准委员会（WG21）的一封《Profiles内存安全框架支持备忘录》中敲响了警钟。他写道：“这不是一份常规的技术提案，不是加个新功能或库那么简单。这是紧急行动的号召，回应C++面临的空前严重的“攻击”。WG21得干点大事，还得让大家看见，Profiles就是最有力的反击武器。”

他语气虽冷静，但字里行间透着焦急：“我对此感受强烈，别被我平静的措辞骗了。”他提到，美国政府的CISA报告要求到2026年淘汰内存不安全语言，这是个“可信的威胁”。Stroustrup认为，这不仅是危机，也是机遇——C++从诞生之初就追求类型安全和资源安全（包括内存安全），现在是时候亮出底牌了。

这不是Stroustrup第一次这么激动。2018年，他就曾警告C++社区别乱加功能，称“我们正走向一条可能毁掉C++的路，得赶紧回头！”

如今，他再度站出来，将矛头直指Rust的“舆论霸权”。2月13日，他在安全小组SG23的邮件列表中反驳质疑者：“看看CISA的报告吧。到2026年不解决内存安全，C++就真危险了。”

Stroustrup是位行事低调，谨言慎行的程序员大V，不像Linux之父Linus Torvalds喜欢“放炮”。所以，他这番炮轰“Rust舆论霸权”的罕见强硬表态，足以让C++社区为之一振。

Stroustrup的应对思路很明确：C++得进化，而不是被终结。他提出的Profiles框架，是想通过现代工具和测试，让C++代码逐步变得更安全。早在2022年回应Russinovich的“弃C++用Rust”倡议时，他就说过：“安全当然重要，所以我多年来一直在提升C++的安全性。但这得是个渐进的过程，不是砸了C++换个新玩具。”

谷歌算是Stroustrup的盟友。谷歌承认，C和C++的遗留代码还会存在多年，得好好管理。但就在本周，谷歌的态度开始变得决绝：“我们要彻底消灭内存安全漏洞，不止为自己，也为下一代。”这话听着，更像是押注内存安全语言，而不是修补C++。

时间紧迫。CISA的2026年大限只剩不到两年，C++社区的自救方案能赶上吗？TrapC项目的负责人Robin Rowe不看好Profiles。他在接受The Register采访时指出：“Profiles得给代码打标记强制执行安全规则，有些C++功能会直接罢工。就像Linux编译器的-Wall和-Wextra警告，但不是报错，而是直接关掉指针或数组。”他举例，传统C循环得改成C++的for-each循环，用std::vector替代数组，等于逼程序员按最新C++核心指南重写代码。

Rowe质疑：“没人指望Profiles能在2026年前标准化并集成到编译器里。”他自己的TrapC项目倒是信心满满，预计今年晚些时候就能推出，声称能让所有指针变成“内存安全指针”（MSP），杜绝缓冲区溢出和段错误。他的提案已在2月27日奥地利ISO C委员会会议上亮相，试图为C语言加个安全扩展。

内存安全这事儿，没那么黑白分明。剑桥大学客座研究员David Chisnall在SG23邮件中泼了盆冷水：“现在很少有东西只用一种语言写，跨语言的内存安全更关键。比如Rust核心配Lua脚本，Lua不尊重Rust的独占模型，交互就很难安全。”他认为，与其全盘改用Rust，不如让C和C++更安全。

Chisnall的逻辑很现实：“一次性重写几十亿行代码是个灾难。即使结果内存安全，重写引入的新bug可能是安全噩梦。C到现代C++，再到更安全的C++，这种渐进迁移才是正道。”他帮C++说了句公道话：一点点改，总比推倒重来靠谱。

Rowe也提醒，Rust并非完美。Rust程序员用“unsafe”关键字就能开个不安全的口子，调用C的指针，这种做法在Rust社区里并不少见。“内存安全语言的子集方案，都可能留下漏洞。”他说，TrapC的全面检查才更靠谱。

Chisnall提到：“特朗普一上台就清空了白宫网站，炒了不少CISA搞内存安全的人。”若内存安全不再是政府优先级，C++的压力或许会减轻。但反过来，若欧盟跟进CISA的2026年限令，C++社区的抢救时间就更紧迫了。

内存安全的天要变吗？Stroustrup显然不甘心C++被Rust们彻底取代。他喊话社区：“这是危机，也是机会。”但现实很骨感：Profiles赶不上2026的末班车，TrapC还在测试，谷歌已偏向新语言。C++的亿万行代码是遗产，也是包袱。重写不现实，修补又嫌慢。

对程序员来说，C++的命运不只是技术选择。Rowe说得直白：“没人想重写代码，但没人想用不安全的语言。”Chisnall的渐进路线听着靠谱，可谁来写这个“从C到安全C++”的故事？C++也许还能抢救一下，但时间不等人。

参考链接：

https://www.theregister.com/2025/03/02/c_creator_calls_for_action/