Memory Safety Absolutists
Memory Safety Absolutists
Written by Piotr Sarnacki on July 28, 2026
When seeing the title of this post, I bet in some people’s minds, the first thought was “Rust devs!”. This connection is not unfounded. Rust devs tend to be passionate about memory safety. Some of it, I’m sure, may have been caused by a classic language wars attitude: my language is better than yours, and here is why. I’m hoping, though, that most of the Rust devs, who say they care about memory safety, genuinely care about making software safer, and not just criticizing languages that compete with Rust.
看到这篇文章的标题时，我敢打赌有些人脑海中浮现的第一个念头是“Rust 开发者！”这种联想并非毫无根据。Rust 开发者往往对内存安全充满热情。我相信，其中一部分原因可能源于经典的语言战争心态：我的语言比你的好，原因如下。但我希望，大多数声称关心内存安全的 Rust 开发者，是真心希望让软件变得更安全，而不仅仅是为了批评与 Rust 竞争的语言。
The article, surprisingly, is not about Rust devs. Until recently, most of the memory safety related discourse had a relatively simple basis, at least when considering non-GC, systems programming languages, like C, C++, Zig, and Rust. Rust aims to disallow compiling programs that may introduce memory safety issues (at a cost of sometimes disallowing a program that would have been safe), with an escape hatch in the form of unsafe that allows, among other things, dereferencing raw pointers. C and others leave ensuring memory safety to the programmer. The amount of help from the language differs, for example there is RAII and smart pointers in C++, or defer in Zig, but for the most part nothing stops you from violating memory access.
令人惊讶的是，本文并非关于 Rust 开发者。直到最近，大多数关于内存安全的讨论都有一个相对简单的基础，至少在考虑非垃圾回收（GC）的系统编程语言（如 C、C++、Zig 和 Rust）时是这样。Rust 的目标是禁止编译可能引入内存安全问题的程序（代价是有时会禁止掉本应安全的程序），并提供了一个名为 unsafe 的逃生舱，允许解引用原始指针等操作。而 C 等语言则将确保内存安全的责任留给了程序员。语言提供的帮助程度各不相同，例如 C++ 中的 RAII 和智能指针，或者 Zig 中的 defer，但在大多数情况下，没有什么能阻止你进行违规的内存访问。
The situation today is a bit different with a new way to make C, C++, and in the future maybe also Zig, code memory safe: Fil-C. C and C++ code compiled with Fil-C will panic on invalid memory access, like out of bounds access, or use after free. It achieves it by combining GC and InvisiCaps - a way to track memory accessible by a pointer. Zig’s author recently announced a new compilation mode for Zig inspired by Fil-C. Fil-C is a very interesting project and I sincerely hope it will succeed and at least some popular C and C++ projects will provide Fil-C compiled releases.
如今情况有所不同，出现了一种让 C、C++ 以及未来可能包括 Zig 代码实现内存安全的新方法：Fil-C。使用 Fil-C 编译的 C 和 C++ 代码在遇到无效内存访问（如越界访问或释放后使用）时会触发 panic。它通过结合 GC 和 InvisiCaps（一种追踪指针可访问内存的方法）来实现这一点。Zig 的作者最近宣布了一种受 Fil-C 启发、为 Zig 设计的新编译模式。Fil-C 是一个非常有趣的项目，我衷心希望它能成功，并至少有一些流行的 C 和 C++ 项目能提供 Fil-C 编译的版本。
In an ideal world both Rust programmers and C/C++/Zig programmers that care about memory safety would be happy that there are more ways to minimize memory safety vulnerabilities, but alas, we’re not living in an ideal world and I can’t shake the feeling a lot of the criticism towards Rust recently is disingenuous. If you read Fil-C’s author opinions on Twitter you can find a huge number of claims Rust is a memory unsafe language because of ability to bypass some of the Rust guarantees when using unsafe. Andrew Kelley, Zig’s author, seems to have a similar stance demonstrated in the fil compilation mode issue title: “introduce an actually memory safe (unlike Rust) compilation mode inspired by Fil-C”. Meaning: Rust is unsafe and only Fil-C or Zig’s “fil” compilation mode will deal with memory safety related vulnerabilities.
在理想世界中，无论是 Rust 程序员还是关心内存安全的 C/C++/Zig 程序员，都会为有更多方法来减少内存安全漏洞而感到高兴。但遗憾的是，我们并非生活在理想世界中，我总有一种感觉，最近针对 Rust 的许多批评是不真诚的。如果你阅读 Fil-C 作者在 Twitter 上的观点，会发现大量声称 Rust 是一种内存不安全语言的言论，理由是使用 unsafe 时可以绕过 Rust 的某些保证。Zig 的作者 Andrew Kelley 似乎也有类似的立场，这体现在 fil 编译模式的议题标题中：“引入一种受 Fil-C 启发、真正内存安全（与 Rust 不同）的编译模式”。这意味着：Rust 是不安全的，只有 Fil-C 或 Zig 的“fil”编译模式才能解决内存安全相关的漏洞。
In discussions related to Rust and Fil-C, I’ve often seen a claim similar to: “if Rust folks really cared about memory safety, they would promote Fil-C and ditch Rust as Fil-C is safer, otherwise they just care about their new shiny language, and not memory safety”. That includes Fil-C’s author himself. I’m not sure about Andrew Kelley, but the issue title I mentioned earlier feels awfully close. These kinds of arguments are, in my opinion, ignoring reality, and feel like fanaticism and cult-like behaviour that often Rust devs are accused of.
在关于 Rust 和 Fil-C 的讨论中，我经常看到类似的说法：“如果 Rust 的拥护者真的关心内存安全，他们就应该推广 Fil-C 并放弃 Rust，因为 Fil-C 更安全；否则，他们只是关心他们那门闪亮的新语言，而不是内存安全”。这甚至包括 Fil-C 的作者本人。我不确定 Andrew Kelley 的想法，但我前面提到的那个议题标题感觉非常接近这种论调。在我看来，这类论点无视现实，感觉就像是 Rust 开发者经常被指责的那种狂热和邪教般的行为。
If Fil-C was a drop in replacement with absolutely zero trade-offs, I would maybe partially agree with the sentiment, but it has trade-offs: it’s ABI incompatible with non-Fil-C compiled programs, it may be a few times slower in some cases, and it introduces GC. None of these things is a deal breaker for some programs. A lot of programs you use daily could be a few times slower than they are, and you wouldn’t even notice. A lot of them also don’t link anything dynamically, so the ABI compatibility doesn’t matter. But not every software program is a simple utility. There are lots of popular projects, where GC and ABI incompatibility are an issue and there is no way they would ever start using Fil-C like technology, or at least not in a current form.
如果 Fil-C 是一个完全没有代价的直接替代品，我或许会部分同意这种观点，但它确实存在代价：它与非 Fil-C 编译的程序 ABI 不兼容，在某些情况下可能会慢几倍，并且引入了 GC。对于某些程序来说，这些都不是致命伤。你每天使用的许多程序即使慢上几倍，你甚至都不会察觉。其中许多程序也不进行动态链接，因此 ABI 兼容性并不重要。但并非每个软件程序都是简单的工具。有许多流行的项目，GC 和 ABI 不兼容是核心问题，它们绝不可能开始使用类似 Fil-C 的技术，至少在目前的形式下是不可能的。
Crucially, the kind of programs that can’t use Fil-C are often a good fit for Rust. But Rust is unsafe, isn’t it? It has unsafe after all! If you want to be that strict, or in other words, if you are a memory safety absolutist, that may well be true for you. I, and I hope most people, am more pragmatic than that. There is not a whole lot of data on how secure Rust really is in practice, but to my knowledge there hasn’t been a lot of exploitable memory safety vulnerabilities in Rust software, and there are big projects with some data, like 5M+ LOC in Android:
至关重要的是，那些无法使用 Fil-C 的程序往往非常适合用 Rust 编写。但 Rust 不是不安全吗？毕竟它有 unsafe！如果你想如此严格，换句话说，如果你是一个内存安全绝对主义者，那对你来说确实如此。但我，也希望大多数人，比这更务实。目前关于 Rust 在实践中到底有多安全的数据并不多，但据我所知，Rust 软件中并没有出现太多可利用的内存安全漏洞，而且有一些大型项目提供了数据，例如 Android 中超过 500 万行的代码：
With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC). Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.
“在 Android 平台中，大约有 500 万行 Rust 代码，仅发现了一个潜在的内存安全漏洞（并在发布前已修复），我们估计 Rust 的漏洞密度为每百万行（MLOC）0.2 个漏洞。我们 C 和 C++ 的历史数据则显示，其密度接近每百万行 1,000 个内存安全漏洞。我们目前的 Rust 代码漏洞密度低了几个数量级：减少了 1000 倍以上。”
I’m sure these numbers would differ for other projects, but I think by now it is well established that, in practice, Rust minimizes the risk of introducing memory safety issues. If you could choose a technology that prevents 99.9% of issues in 100% of programs or 100% of issues in 90% of programs, which one would you choose? I have no idea what are the real numbers, but you get the point. Thankfully, we don’t have to choose one or the other, contrary to what some people would claim. I would hope that projects written in C/C++/Zig, that can accept the trade-offs, will be available as Fil-C compiled binaries, and software that can’t, will be written in languages that either completely or mostly remove the risk of introducing memory safety vulnerabilities. And I also think it is totally fine to use Rust even if you could use a GC language like Go or Fil-C. Memory safety absolutists would tell you that’s not acceptable, although so…
我相信这些数字在其他项目中会有所不同，但我认为现在已经可以确定，在实践中，Rust 最大限度地降低了引入内存安全问题的风险。如果你可以选择一种技术，要么在 100% 的程序中预防 99.9% 的问题，要么在 90% 的程序中预防 100% 的问题，你会选择哪一个？我不知道真实的数字是多少，但你明白我的意思。值得庆幸的是，与某些人的说法相反，我们不必二选一。我希望那些能够接受代价的 C/C++/Zig 项目能提供 Fil-C 编译的二进制文件，而无法接受的软件则应使用能完全或大部分消除内存安全漏洞风险的语言编写。我也认为，即使你可以使用像 Go 或 Fil-C 这样的 GC 语言，使用 Rust 也完全没问题。内存安全绝对主义者会告诉你这是不可接受的，尽管如此……