在分析了从 2014 年 7 月 15 日到 2023 年 12 月 14 日近 10 年的 CVE 后，谷歌研究人员计算得出，在 C++ 中，至少 40% 的安全漏洞与空间内存漏洞（如越界写入内存）有关。

　　谷歌研究人员 表示，他们能够将空间安全 “加装 ”到 C++ 代码库中，而且对性能的影响非常非常小。网上有一篇 关于他们研究成果的博文，引发了更为广泛的讨论，其中不乏一些有趣的跟帖，有人甚至大声质疑，这种低影响是否意味着 C++ 代码可以默认包含空间内存安全特性。

　　该文还提出了一种可能性，即一些已经存在很长时间的假设可能会随着时间的推移而受到挑战——当面临的问题比较严重时，或许可以尝试引入新技术。

　　这一切都源于一篇博文，该文描述了谷歌如何通过在 C++ 代码中添加边界检查来保护其服务器端生产系统，从而提高 Gmail、YouTube、谷歌地图甚至谷歌搜索引擎的安全性。谷歌是内存安全语言和其他安全编码实践的早期采用者，但全面过渡往往需要数年时间。也就是说，他们还需要额外做一些工作：“尽可能地在现有 C++ 代码库中改用安全设计原则。

　　该博文由资深软件工程师 Alex Rebert 和 Kinuko Yasuda（与谷歌的 Max Shavrick 合作，后者也是安全基础团队的成员）撰写。该文首先指出，C++ 标准库的 LLVM 实现中包括几种用于发现未定义行为的加固模式，从而可以对 C++ 代码进行边界检查。

　　该团队发现了 1000 多个 Bug。（据谷歌估计，平均每年发现的 Bug 可增加到 1000 至 2000 个）。

　　谷歌 “整个生产环境的基线%”。在博文中，他们将此归功于更好的代码可靠性和质量：“除了崩溃之外，检查还发现了一些错误。这些错误可能会表现为不可预测的行为或损坏数据。

　　最终，它还帮助谷歌 “发现并修复了多个在代码中潜伏了十多年的 Bug”。经过加固的 C++ 检查 “将许多难以诊断的内存损坏转化为即时且易于调试的错误”。

　　其中有一项结果最引人关注。谷歌的博文称，加固libc++“对我们的服务平均造成了 0.30% 的性能影响”。

　　谷歌杰出工程师Chandler Carruth回应了他们的博文。他也是新兴编程语言 Carbon的创始人和联合牵头人。Carruth 撰写了一篇博文，其中第一节的标题就是 边界检查的开销：我错了。

　　“其他人关于成本的一些历史报告，再加上我自己的一些简单实验，让我坚定地认为，边界检查的成本不可能低到可以默认启用的程度。然而，到目前为止，它们看起来确实非常低翻墙连接谷歌商店。“

　　遗憾的是，这种普遍的看法使得高质量的动态安全检查没有出现在 libc++ 及其他 C++ 库中，最初也没有出现在 LLVM 中。

　　但 Carruth 看到，Microsoft Visual C++ 引入了基于编译器的检查，而 “在这里，苹果公司所有推动 在 C++ 中实现安全缓冲区 的人都做了一项了不起的工作，让 LLVM 生态系统（包括 Clang 和 libc++）最终在这一领域拥有了一个可靠的工具”。Carruth 认为，另一个因素是内存安全语言开发人员为 LLVM 做出了更多的贡献（因为更多的非 C/C++ 语言开始使用 LLVM），从而带来了 “一系列稳定而系统化的改进”。

　　回首过去，Carruth 认为，虽然 LLVM 经过了多年的改进，但我们并没有真正注意到什么时候已经达到了一个临界点。在那一刻，所有改进一起从根本上降低了此类检查的实际成本，使其在默认情况下就普遍适用。“

　　“这种水平的可用性改变了安全游戏的规则，因为我们不用再在性能或安全性之间做出痛苦的权衡取舍，我们可以两者兼得。“

　　Carruth 用粗体字写道：我认为，通过努力，借助编译器对内存安全检查的持续支持，我们确实有机会默认实现空间内存安全，即使是在 C 和 C++ 中，即使是在性能最受限制的环境中。”

　　这就提出了一个问题：现在是否应该考虑下参考计数等其他安全检查——即使我们认为这些检查会带来令人望而却步的性能影响。

　　“我认为，有足够的证明表明，对于比较小的系统（手机、笔记本电脑、其他用电池的东西），缓存流量和潜在同步开销的成本即使再大也微不足道。我认为，Swift 已经提供了强有力的证据，只要在优化基础设施上投入一些资金并认真实施，参考计数就能够在这些处理器上实现极高的效率。”