[im3w1l]

It should be mentioned that rust's type system has a long-standing known bug compromising memory safety, as made famous by cve-rs. It's perhaps not a big issue for most people but if you are someone that wants the assurances of #![forbid(unsafe_code)] that should probably be on your radar.

[kibwen]

Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates its ability to realistically eliminate memory safety risks.

[im3w1l]

A known bug with easily accessible proof-of-concept is quite different from a theoretical bug.

[kibwen]

No, that's not how this works. The bug being utilized by cve-rs has such roundabout requirements that it's unlikely that anyone has ever triggered it without trying (to be clear, the Rust devs plan to fix it regardless). Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: https://www.reddit.com/r/cpp/comments/1v4nw0k/filc_garbage_i...

[MaulingMonkey]

I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them:

• `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`.

• `std::env::set_var(...)`. It's now marked `unsafe`. While I dodged the bullet, these fellows didn't: https://www.geldata.com/blog/c-stdlib-isn-t-threadsafe-and-e...

• `#[no_mangle]`. It's now `#[unsafe(no_mangle)]`.

I don't believe I've constructed cvs-rs's hole by accident. cve-rs's code links to https://github.com/rust-lang/rust/issues/25860 , which is admittedly still open after a decade. Progress appears to still be ongoing though! Related:

• https://github.com/orgs/rust-lang/projects/44/views/1

• https://rust-lang.github.io/rust-project-goals/2025h2/next-s...

> Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: [...]

Thanks for sharing a concrete example of Fil-C's limitations! Disappointing - but not unexpected - to see it underperforming existing sanitizers. I was hoping for better.

[kibwen]

> I've encountered a few soundness holes in rust-lang in practice

Indeed, I'm trying to be careful not to claim that merely fixing #25860 at long last would make Rust's implementation suddenly beyond reproach. For that, we would need formal verification (which, so far, has at least been done by Ralf Jung's group for proving the correctness of large swathes of the standard library, but I wouldn't expect that to extend to the compiler anytime soon).