C++ 之父呼吁社区共同捍卫编程语言免受"严重攻击"

C++ 的创始人 Bjarne Stroustrup 发出呼吁，希望 C++ 社区团结一致，共同保护这门编程语言。近年来，由于内存安全性方面的缺陷，C++ 一直受到网络安全机构和技术专家的质疑。

C 和 C++ 依赖手动内存管理，这可能导致内存安全错误，比如越界读写。这类 bug 在大型代码库中占据了漏洞的主要部分。

随着这些漏洞造成的高调且代价高昂的安全事件频发，近三四年来，业界和政府网络安全专家开始discourage使用 C 和 C++，转而推广具有更好内存安全性的语言，如 Rust、Go、C#、Java、Swift、Python 和 JavaScript。

C/C++ 社区已经提出了多个朝着内存安全方向发展的提案，包括 TrapC、FilC、Mini-C 和 Safe C++ 等。

作为哥伦比亚大学计算机科学教授的 Stroustrup 发出警告，表明问题不仅仅在于进展缓慢，更在于缺乏能够与科技行业对 Rust 的推崇相抗衡的公共叙事。

在 2 月 7 日提交给 C++ 标准委员会 (WG21) 的一份关于其 Profiles 内存安全框架的"说明"中，他写道："这显然不是一个传统的技术说明，提出新的语言或库特性。这是一个紧急行动的呼吁，部分是为了应对前所未有的、对 C++ 的严重攻击。我认为 WG21 需要做出重大行动，并让这些行动被看到。Profiles 是一个可以实现这一目标的框架。"

他继续写道："正如我之前所说，这也是一个机会，因为类型安全和资源安全 (包括内存安全) 从一开始就是 C++ 的主要目标。我对此感受很深。请不要被我相对平静的语言所迷惑。"

Stroustrup 并不以 Torvalds 式的尖刻或夸张著称。据我们所知，他上一次使用如此强烈的语言是在 2018 年，当时他要求 C++ 社区放慢脚步，以更协调的方式提出语言改进。他当时警告说："我们正走在可能毁灭 C++ 的道路上。我们必须改变这条路！"

在 2 月 13 日发给安全专注组 SG23 邮件列表的消息中，针对有人质疑 C++ 是否真的面临威胁，Stroustrup 指出了美国政府 CISA 去年 10 月发布的产品安全不良实践报告。

该报告指出，到 2026 年 1 月 1 日，制造商应该为使用内存不安全语言的产品制定内存安全路线图，以消除内存安全漏洞，或者采用内存安全的编程语言。Stroustrup 表示："我认为这是一个可信的威胁。"

在本文撰写时正在国外旅行的 Stroustrup 告诉 The Register，他希望进一步详细阐述这个问题，但担心仓促的回应可能会被误解或断章取义。不过他同意引用他在邮件列表中的言论。

Stroustrup 很清楚业界对内存安全编程的日益重视。2022 年，当 Microsoft Azure CTO Mark Russinovich 呼吁"停止启动任何新的 C/C++ 项目，在需要非垃圾回收语言的场景中使用 Rust"时，他就直接回应了这些担忧。

Linux 社区支持在内核代码中采用 Rust，认为其崛起是必然的

是时候让 C 语言成为本世纪的 COBOL 了

联邦政府希望开发者停止编写"不可原谅的"缓冲区溢出漏洞

Linux 内核维护者将混合使用 Rust 和 C 比作癌症

Stroustrup 对 Russinovich 的言论不以为然，认为这只是对新语言的一时痴迷，他表示："安全性在许多场景下显然至关重要，所以我多年来一直致力于提高 C++ 的安全性。"

他呼吁采取渐进式方法——通过测试和工具使 C++ 代码更安全，而不是彻底抛弃 C++。

Google 也支持这一立场，承认传统的 C 和 C++ 还将存在多年，需要进行管理。

但就在本周，这家搜索引擎巨头明确表示，他们更关注内存安全的未来，而不是现代化 C/C++。

该公司表示："我们呼吁一个根本性的转变：集体承诺最终消除这类 [内存安全] 漏洞，以安全设计实践为基础——不仅是为了我们自己，也是为了后代。"

考虑到 CISA 呼吁在 2026 年前弃用 C/C++，C/C++ 社区已经没有太多时间来响应了。

TrapC 项目负责人 Robin Rowe 不认为 Profiles 能够及时到位，也不认为这是一个实用的解决方案。

他告诉 The Register："如果你标记代码以强制执行 Profile，C/C++ 语言的某些特性将停止工作。这就像 Linux 中的 -Wall 和 -Wextra 编译器标志，只不过不是将警告升级为错误，而是关闭指针或数组。"

Rowe 解释说，C++ 程序员会用 Profile 标记他们的代码，然后重写因 Profile 限制而失效的部分。

"例如，遍历 C 数组的 C for 循环必须替换为使用 std::vector 的 C++ for-each 循环，"他说，这是一个强制 C++ 程序员使用最新 C++ 核心指南重写代码的机制。

"没有人说 C++ Profiles 会在 2026 年之前被 ISO C++ 委员会标准化，或在编译器中实现，"Rowe 说，他同样怀疑 DARPA 的 TRACTOR 项目（用于自动 C 到 Rust 转换）能否在那时准备就绪。

Rowe 在这场竞争中也有自己的筹码——他最近向 ISO C 委员会展示了他的 TrapC 编译器工作，预计将于今年晚些时候准备就绪，作为 C 编程语言的潜在扩展。2 月 27 日星期四，他在奥地利格拉茨举行的 ISO C 委员会标准机构会议上回答了有关该项目的问题。

"TrapC 内存安全指针 (MSP) 不会缓冲区溢出，也不会出现段错误，"他说。"当使用 TrapC 编译器编译 C 代码时，所有指针都会变成 MSP 并受到检查。"

Rowe 认为其他 C 和 C++ 内存安全方案并不全面。"程序员可配置的 C/C++ 编程语言子集的弱点，无论是 C++ Profiles、C 扩展 N3211 还是其他，在于内存安全性无法保证在所有编译单元中保持一致，"他解释道。

"Rust 也不能幸免，同样存在漏洞。Rust 程序可能会使用 Rust 的 'unsafe' 关键字打开一个漏洞，并广泛用于访问众所周知的不安全 C 指针。"

剑桥大学访问研究员、基于 CHERI (Capability Hardware Enhanced RISC Instructions) 制造内存安全硬件的 SCI Semiconductor 系统架构总监 David Chisnall，对 Stroustrup 在 SG23 的紧急呼吁中提到的语言层面的内存安全解决方案表示怀疑。

"现在很少有程序只用单一语言编写，跨语言的内存安全很重要，"他写道。"如果你用 Rust 编写核心，用 Lua 脚本，但 Lua 不遵守 Rust 的唯一所有权模型，那么就很难安全地互操作。安全互操作的工具很重要。"

Chisnall 认为，使 C 和 C++ 更安全比用 Rust 或其他内存安全语言重写代码是更好的方法。

他解释说："从 C 到当前 C++，再到具有更强安全性的 C++，渐进式迁移是一个很好的方案，因为你可以一步一步来。一次性重写数十亿行代码是个问题：即使最终结果是内存安全的，重写代码也会引入 bug，其中很多会影响安全性或关键安全。销售一个从 C 到安全 C++ 方言的迁移方案，让人们可以在多年内逐步完成，这对 C++ 来说会很好。"

谁将成为这个故事的作者还有待观察。

也就是说，如果内存安全仍然是政府关注的问题。正如 Chisnall 所观察到的："新的美国政府已经从白宫网站上删除了所有内容，并解雇了大多数从事内存安全工作的 CISA 人员..." (R)