The first thing I always look for is mutability (combined with some other tricky feature), e.g. "Now it's a Just(3):Maybe<Int>, now it's a Nothing:Maybe<Int>, now it's a Nothing:Maybe<String>."
I wonder if TFA's example could be reproduced without mutability.
so what I take from this is that the rust compiler does not guarantee the stuff it claims to. Because new features of the type system is just being yolod instead of formally proven
There never was formal verification of the entire rust compiler, or even its complete borrow checker/type system. There has been verifications on _subsets_ of them.
Also, a lot of those soundness issues aren't related to new features _at all_, but usually due to poor assumptions made in optimizations.
The soundness bugs _are_ taken seriously though, and are slowly being patched out. A lot of the links in OP are now closed because Rust either changed how it generates code to avoid the issues, or fixed LLVM.
No mainstream compiler is formally proven. If you want a verified compiler, you pretty much have to choose between using a subset of standardml or a subset of C and the one proven compiler for each.
Yes. When people describe Rust as "a memory-safe programming language" they are describing an aspirational vision, and not a programming language that has actually been designed with sufficient rigor to guarantee memory safety. Any failure of rustc to actually guarantee this is just a bug in rustc itself, a failure to properly implement the Rust spec, because the closest thing Rust has to a spec is literally just the vague ideal that the compiler should guarantee safety somehow.
This is remarkable but not super unusual. There are more than 100 issues labeled unsound currently. Some are long standing but from what I understand the new trait solver will unblock fixes for some of them (but probably not the one in OP).
Perhaps ironically, AI-based searching of the Rust compiler for bugs is likely to find more of these, pushing Rust closer and closer to the point of complete reliability.
The eventual formalization of Rust and a creation of a formally proven compiler is presumably going to be the end point of this process.
There is a formally proven compiler for a large subset of C, so I don't see why formalizing (a large subset of) rust and making a formally proven compiler shouldn't be possible
Took me a good couple minutes to wrap my head around. Man, what a nasty bug. I guess this specific use-case is rare. Time to see if any of the big libs are affected...
What the hell. This is not the esoteric, crazy, impractical constellation I expected to find with a title like this. The minimal example is so simple and is definitely something you'd easily come across in normal code.
I wonder if the reason it works is because you'd easily come across it in normal code, and someone didn't realize that saving the effort of implementing a check for this would result in unsoundness.
Not really. I've worked with rust for 4 years, systems side, and never had to write a custom drop implementation. That's the gotcha here, not the rigamarole with the static+Send option type (which _would_ be something you'd encounter in prod).
A custom `Drop` appears very quickly with FFI code. Suppose for example you interface with some C library that expects you to call a function to release some resources.
Old C software is generally more trustworthy than new C software. I don't think this rule of thumb transfers across languages very well. And the definition of new vs old has a fairly large effect. If a language has been under constant change it doesn't matter when it was started a large part of the codebase is "new".
Worked on a variance-related lint once and the scary part is how rarely anyone writes down variance by hand, so bugs there just sit untested for a decade.
I think it has no relevance here at all. Actix was unsound because of prolific use of unsafe. That was a poor design decision but a conscious one. TFA is just a bug.
Rust is good, I generally do not dislike it - but it does have flaws.
I will happily continue to write things in Golang first. I don't enjoy refactors in Rust, and it's rare that I see things that genuinely need its raw performance.
Cloudflare's Oxy is a stellar example of build in Golang till your design is settled and then port over for performance when you need it.
Here's the weakness of compiled programs. Does this compiled code have this vulnerability? You have no idea. At least with a VM or interpreter you can scan for vulnerable versions and replace the runtime or the specific library.
struct Q<T: 'static>(Option<T>);
impl<T: 'static> Drop for Q<T> {
fn drop(&mut self) {
// Code in here has access to a non-'static &String
// but assumes that it's a &'static String
}
}
fn main() {
let l = String::new();
let mut q = Q(None);
q.0 = Some(&l);
}
I wonder if the certified compiler for safety critical uses (edit: Ferrocene) has the same issue.
chatgpt and grok linked to the the soundness issue, claude I am in usage timeout, and gemini shit the bed as usual: "The compiler rejects the program with error[E0597] on the assignment q.0 = Some(&l)"
This is not the first soundness bug. Some bugs aren't fixed for years. The Rust community is well aware that such bugs exist, will be found, and address them just like other high impact bugs. In other words, if you paid the slightest attention to the development of Rust language, you would know this is surprising but not unexpected, and has happened many times.
Given that TFA is currently #1 on HN, I suspect I'm not the only person who is aware of Rust's borrow checker but not aware, until now, that it has a history of serious soundness bugs.
It looks like 18 of the 30 issues listed in table 4 had already been fixed when that paper was released, and there is activity in most of the rest. One was recently flagged as being fixed by -Znext-solver, and another has the submitter write that it is fixed, but the issue is not closed. And that's before you consider the impact of the individual issues; how many of the remaining issues impact "real" code?
So I don't think it's fair to claim that "no-one cared".
I don't think "no one cared" is a fair characterisation. The paper doesn't support this conclusion, and from experience I'd say that the two difficulties in fixing unsoundness are doing so without breaking existing code (Rust guarantees stability unless the code is unsound, and introducing previously missing checks can cause sound code to stop compiling, which is a problem if it occurs often) and doing so in a reliable way that can be supported long-term. Rust is currently in the progress of stabilizing next-solver and Polonius, both of which fix multiple long-standing bugs and have been worked on for years now due to intrinsic complexity, performance considerations, compatibility issues, etc. It's not that no one cares, it's just that this stuff is hard and takes time.
Rust is not a memory-safe language. cve-rs proved it years ago but commenters always argue that cve-rs is too contrived to matter, or that it's a compiler bug so it doesn't count.
Literally nothing can be anything in absolute terms, what's your point? The fact is that Rust is miles better than any other language in terms of memory safety & performance ratio. That's all that matters.
But bugfixes are also allowed. So the fair conclusion is that the implementation is broken, but the language is not - because it's possible to fix, and it's possible for all known soundness issues (including the cve-rs one). For this one specifically, I've heard people are already working on a fix.
Lifetimes can be effectively erased via covariant assignment.
It's in the title.
Even a beginner could understand these assignments are not in spec?
Are you just being contrary to be contrary?
If that's the definition you're using, then C is also a safe programming language. In fact, C is even safer, because it actually does have a specification that lists all the invariants that the programmer has to uphold themselves because the compiler doesn't check them.
Specifically the `q.0 = Some(&l);` violating 4.15.2:40 ("An assignment expression requires that the type of its value operand is a subtype of the type of its assignee operand.")
I totally understand that people have favourite languages and that rust, like any language and any ecosystem around that language, has idiosyncrasies that are not for everyone, but how would one ever come to the genuine conclusion that rust is not being taken seriously? By whom?
Type systems are hard! Check out https://counterexamples.org/
I gave it a quick scan for Rust examples; there are 11 samples among the following pages:
The first thing I always look for is mutability (combined with some other tricky feature), e.g. "Now it's a Just(3):Maybe<Int>, now it's a Nothing:Maybe<Int>, now it's a Nothing:Maybe<String>."I wonder if TFA's example could be reproduced without mutability.
so what I take from this is that the rust compiler does not guarantee the stuff it claims to. Because new features of the type system is just being yolod instead of formally proven
There never was formal verification of the entire rust compiler, or even its complete borrow checker/type system. There has been verifications on _subsets_ of them.
Also, a lot of those soundness issues aren't related to new features _at all_, but usually due to poor assumptions made in optimizations.
The soundness bugs _are_ taken seriously though, and are slowly being patched out. A lot of the links in OP are now closed because Rust either changed how it generates code to avoid the issues, or fixed LLVM.
No mainstream compiler is formally proven. If you want a verified compiler, you pretty much have to choose between using a subset of standardml or a subset of C and the one proven compiler for each.
There is a massive possibility space between “yolo” and formal proof. Rust has substantial evidence of correctness. For example, unit tests and types.
The Java type system is also unsound. That’s life. It is hard to do this fully correctly. In practice this never comes up.
Yes. When people describe Rust as "a memory-safe programming language" they are describing an aspirational vision, and not a programming language that has actually been designed with sufficient rigor to guarantee memory safety. Any failure of rustc to actually guarantee this is just a bug in rustc itself, a failure to properly implement the Rust spec, because the closest thing Rust has to a spec is literally just the vague ideal that the compiler should guarantee safety somehow.
Rust cannot fail, it can only be failed.
Would you say the same thing about Java? It’s type system is also unsound.
>Rust cannot fail, it can only be failed...
Sweet. But why should anyone care..
This is remarkable but not super unusual. There are more than 100 issues labeled unsound currently. Some are long standing but from what I understand the new trait solver will unblock fixes for some of them (but probably not the one in OP).
Perhaps ironically, AI-based searching of the Rust compiler for bugs is likely to find more of these, pushing Rust closer and closer to the point of complete reliability.
The eventual formalization of Rust and a creation of a formally proven compiler is presumably going to be the end point of this process.
Or we realize that it is not possible, and Rust accepts to be "just" a definitely safer C.
There is a formally proven compiler for a large subset of C, so I don't see why formalizing (a large subset of) rust and making a formally proven compiler shouldn't be possible
Because people want a performant optimizing compiler.
Until they find bugs in the formal proof program ;)
https://www.lesswrong.com/posts/zHhGa3iQBQcdSifFL/a-critical...
Took me a good couple minutes to wrap my head around. Man, what a nasty bug. I guess this specific use-case is rare. Time to see if any of the big libs are affected...
What the hell. This is not the esoteric, crazy, impractical constellation I expected to find with a title like this. The minimal example is so simple and is definitely something you'd easily come across in normal code.
> is definitely something you'd easily come across in normal code.
The fact that nobody reported this before means it's not, by definition.
For a long time `loop {}` was undefined behavior. Lots of l-unsounds are really nuts but a few are not.
The reality is that if this were actually code that people wrote, well, it wouldn't have sat around for a decade.
I wonder if the reason it works is because you'd easily come across it in normal code, and someone didn't realize that saving the effort of implementing a check for this would result in unsoundness.
Not really. I've worked with rust for 4 years, systems side, and never had to write a custom drop implementation. That's the gotcha here, not the rigamarole with the static+Send option type (which _would_ be something you'd encounter in prod).
I've written dozens of custom Drop implementations. Well, many of them are named cleanup because of the async Drop mess in Rust, but...
OK. That's good to know. I'm not sure why sharing our professional experience with this type of code is controversial, but here we are.
How many of them only conditionally implement Drop, based on a generic param lifetime?
That's easily the exception rather than the rule. I've seen custom `Drop` implementations in almost every non-trivial Rust codebase I worked on.
Now we are at the phase where, Rust is “safe” but only if you use it “correctly” and without using X language feature or a custom Y feature.
This is the problem when a language advertises with “guarantees” and it turns out it never had any due to many false assumptions by their promoters.
So what other soundness bugs are there in the language that we need to know about?
I'm not defending rust here - a correctness bug invalidates the premise. But I am saying that I've never seen a custom drop in production.
For some reason this is controversial, but it remains true.
A custom `Drop` appears very quickly with FFI code. Suppose for example you interface with some C library that expects you to call a function to release some resources.
I don't understand how something like this could take so long to be discovered. Pretty crazy stuff.
> I don't understand how something like this could take so long to be discovered.
Maybe they wrote it in C :-)
On a serious note, old software is generally more trustworthy than new software, because bugs are discovered over time and with usage.
Old C software is generally more trustworthy than new C software. I don't think this rule of thumb transfers across languages very well. And the definition of new vs old has a fairly large effect. If a language has been under constant change it doesn't matter when it was started a large part of the codebase is "new".
Because it's rarely used like this, just like weird bugs caused by edge cases found in all kinds of software in the world.
Worked on a variance-related lint once and the scary part is how rarely anyone writes down variance by hand, so bugs there just sit untested for a decade.
wonder what happened to this https://raphlinus.github.io/rust/2020/01/18/soundness-pledge...
I think it has no relevance here at all. Actix was unsound because of prolific use of unsafe. That was a poor design decision but a conscious one. TFA is just a bug.
Having ideals does not mean there are never bugs.
What do you mean?
There is a collection of these someplace. Rust is better but it'll never be perfect, news at 10
Rust is good, I generally do not dislike it - but it does have flaws.
I will happily continue to write things in Golang first. I don't enjoy refactors in Rust, and it's rare that I see things that genuinely need its raw performance.
Cloudflare's Oxy is a stellar example of build in Golang till your design is settled and then port over for performance when you need it.
Here's the weakness of compiled programs. Does this compiled code have this vulnerability? You have no idea. At least with a VM or interpreter you can scan for vulnerable versions and replace the runtime or the specific library.
With this you have to recompile everything
That is less and less true by the day, for better or worse.
The heart of the matter:
I wonder if the certified compiler for safety critical uses (edit: Ferrocene) has the same issue.Can someone ELI5 for people who don't know Rust (but e.g. C)?
> I wonder if the certified compiler for safety critical uses has the same issue.
It uses the same code, so yes.
(Although I don't know what are their guidelines, it might be that they require avoiding code relying on implied bounds, for example).
which compiler?
Ferrocene
DeepSeek v4.1 Flash thinks it should NOT compile. Whereas in reality it DOES compile which is why it is filed as a bug.
They're seriously using AI as a judge for what to file?
The issue and none of the comments mention AI. It is pretty clear your parent said it by themselves.
I was just checking what outcome an LLM would have based on the patterns in its probabilistic distribution it has seen the wild.
Most LLMs would probably say this piece of code won't compile.
chatgpt and grok linked to the the soundness issue, claude I am in usage timeout, and gemini shit the bed as usual: "The compiler rejects the program with error[E0597] on the assignment q.0 = Some(&l)"
very very good job
As an old C++ guy, my take is: Heh heh heh.
ETA: Downvoters, I salute you. Without your selfless courage, the forces of light humour would surely prevail.
This is not the first soundness bug. Some bugs aren't fixed for years. The Rust community is well aware that such bugs exist, will be found, and address them just like other high impact bugs. In other words, if you paid the slightest attention to the development of Rust language, you would know this is surprising but not unexpected, and has happened many times.
Given that TFA is currently #1 on HN, I suspect I'm not the only person who is aware of Rust's borrow checker but not aware, until now, that it has a history of serious soundness bugs.
People in sugar glass houses shouldn't throw stones :P
You got my upvote and this one decade old issue:
https://github.com/rust-lang/rust/issues/25860
You got my upvote.
Yeah. A reminder that no language is a silver bullet even if it is heavily marketed. Especially with the “written in XYZ™” tag line.
This should not be a surprise at all given the amount of soundness bugs that were collected in the Rust compiler but no-one cared. [0]
EDIT: I don’t even think HN cared either up until now. If you search this paper on HN, guess who posted it?
[0] https://arxiv.org/abs/2608.28713
It looks like 18 of the 30 issues listed in table 4 had already been fixed when that paper was released, and there is activity in most of the rest. One was recently flagged as being fixed by -Znext-solver, and another has the submitter write that it is fixed, but the issue is not closed. And that's before you consider the impact of the individual issues; how many of the remaining issues impact "real" code?
So I don't think it's fair to claim that "no-one cared".
I don't think "no one cared" is a fair characterisation. The paper doesn't support this conclusion, and from experience I'd say that the two difficulties in fixing unsoundness are doing so without breaking existing code (Rust guarantees stability unless the code is unsound, and introducing previously missing checks can cause sound code to stop compiling, which is a problem if it occurs often) and doing so in a reliable way that can be supported long-term. Rust is currently in the progress of stabilizing next-solver and Polonius, both of which fix multiple long-standing bugs and have been worked on for years now due to intrinsic complexity, performance considerations, compatibility issues, etc. It's not that no one cares, it's just that this stuff is hard and takes time.
Rust is not a memory-safe language. cve-rs proved it years ago but commenters always argue that cve-rs is too contrived to matter, or that it's a compiler bug so it doesn't count.
lol do you think that cve-rs was required? there is literally an l-unsound tag on rustc's github, this isn't some embarrassing or secret thing.
Safe rust is safe, granting `unsafe` and compiler errors. This isn't a secret.
What's l- here? Literal?
"I" stands for "issue"
https://github.com/rust-lang/rust/labels?q=unsound
lol I was writing `l` because I thought it was `labeled-unsound` for like a fucking decade
in compare to c and cpp? it is
And in absolute terms?
Literally nothing can be anything in absolute terms, what's your point? The fact is that Rust is miles better than any other language in terms of memory safety & performance ratio. That's all that matters.
cmon, it is time move on.
it has been discussed bilion times
Let us not conflate a bug in an implementation (rustc) with a defect in the language (Rust).
AFAIK there isn't a language spec. Rustc is the language for now.
But bugfixes are also allowed. So the fair conclusion is that the implementation is broken, but the language is not - because it's possible to fix, and it's possible for all known soundness issues (including the cve-rs one). For this one specifically, I've heard people are already working on a fix.
If the compiler is the language that implies there is currently a bug in the language, which will be fixed when the compiler is fixed.
My understanding is that it is work in progress, via Ferrocene.
Ferrocene has his same flaw
If that's the case then I was wrong.
Which clause of the language specification is being violated?
Lifetimes can be effectively erased via covariant assignment. It's in the title. Even a beginner could understand these assignments are not in spec? Are you just being contrary to be contrary?
If that's the definition you're using, then C is also a safe programming language. In fact, C is even safer, because it actually does have a specification that lists all the invariants that the programmer has to uphold themselves because the compiler doesn't check them.
So point to the spec
https://public-docs.ferrocene.dev/main/specification/types-a...
Specifically the `q.0 = Some(&l);` violating 4.15.2:40 ("An assignment expression requires that the type of its value operand is a subtype of the type of its assignee operand.")
this is probably a great opportunity for rust to get one, if they want to be taken seriously
I totally understand that people have favourite languages and that rust, like any language and any ecosystem around that language, has idiosyncrasies that are not for everyone, but how would one ever come to the genuine conclusion that rust is not being taken seriously? By whom?