| HN Mirror

> unsound issues

Apparently there's 84 open issues which the Rust developers consider unsound issues. https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

That's it. Rust's claims are over and done with. How can it be safe if it's unsound? By the principle of noncontradiction and the laws of thought itself, let no one speak that word anymore.

You can call Rust memory safer, but until those bugs get fixed, it's wrong to call it safe.

To be fair though, almost every language is unsound in that metric. In fact, only an implementation that is verified and translated from a formal specification with the verifier and translator also similarly verified (ad infinitum) would be sound. Even PL researchers are not that strict---many academic papers don't actually prove the whole soundness, because the proof process is more or less automatic for the vast majority of cases to who know enough PL theories. (I can't say it's "mechanical", since the reasoning is still required. But the reasoning itself is not too involved for intended audiences.)

Just like that not every security vulnerability is equally fatal, not every soundness bug is equally fatal. I reckon about three levels of severity: inherent to the design itself, not inherent to the design but reasonably user-visible, and pathological. As pcwalton pointed out, miri does show that this particular soundness bug is NOT inherent to the language design, and I believe that's true for most of 84 unsound bugs (please let me know any counter-example though, I haven't fully checked them). It remains to be seen whether there exist soundness bugs that are still user-visible enough.

But languages like C / C++ don't claim to be safe.

Even Rust doesn't claim to be "safe" without a qualifier. From the website:

> Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.

Note that it explicitly mentions "memory" safety and "thread" safety, which has a specific but reasonable definition in Rust (for example, memory safety doesn't cover physical memory leak). Also it explicitly mentions which portion of Rust is responsible for such guarantees, namely "type system" and "ownership model", and it is reasonably claimed that the ideal implementation of both will indeed completely achieve such guarantees. To be clear, the current implementation is also very close to that ideal to make such claim meaningful, but there is always a difference between the ideal and the practice.

Then they should say "we're researching how to create a memory safe language" or "we've built a memory-safer language" rather than saying what they're saying.

By that standard, no general-use programming language (even eg Python or Java) could ever be called "memory-safe". That level of pedantry is occasionally necessary, but not usually useful. In practice, I'd confidently wager the vast majority of Rust programmers have never encountered a soundness bug in the core language when not specifically hunting for one (I certainly haven't).

If you like a pedantry, yeah. But it helps to know that almost everyone else don't like that pedantry.

No general-purpose programming language can be "perfectly safe". At the limit, you can always write to `/proc/self/mem`, actuate a robotic arm via USB to smash the CPU, etc.

A large portion of the bugs in that list require unstable language features. Most of the remainder are codegen bugs (miscompilations, ABI mismatches, linker problems, etc). The list of core type system soundness bugs is a lot shorter, it's tracked here: https://github.com/orgs/rust-lang/projects/44

That list of core type system soundness issues is long enough that it'd probably be easier to prove Rust style checks are unsound due to incompleteness / halting problem issues rather than fixing all those issues.

The core of the Rust safety model has been proven sound: https://plv.mpi-sws.org/rustbelt/ If you peruse the list, all the issues are either a) places where the actual implementation falls short of the theoretical model, bit there's a plan to fix it, or b) edge-case interactions with peripheral language features (statics and dynamic dispatch).

int_19h 842 days ago

Statics are hardly a "peripheral language issue", though.

The issue in question, https://github.com/rust-lang/rust/issues/49206, is such an edge case that there are 0 known examples of it causing a problem in practice, despite the issue being around for many years.

The number of GitHub issues does not correlate to the actual number or severity of issues. After all, rust-lang/rust has more than 120K issues and 9K open issues, but it doesn't mean that Rust has too many issues to solve---those GH issues are mostly means to manage tasks or user tickets to track.