For someone who is not a rust dev, would you mind giving me an example of this:
"Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that.
That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that:
But code is not mathematics, so incorrect code is not worthless, it’s just worth less.
It’ll most likely still do 99% of the things people need it to do, there’ll be a an issue created for that broken 1%, and eventually it’ll be iterated upon and fixed.
Unless you’re working on a security boundary of course, there you should treat it like maths.
> So you haven't understood the distinction or you're letting your feelings for software get the best of you.
Maybe? I'm not sure.
> The proof that there are no (for rust's definition of "no") memory bugs becomes worthless
I still don't think so, the proof that there are no memory bugs is definitely not worthless, since while the whole proof itself is binary (it is either fully correct or not), its effects act more like coverage, and the more of it that happens to be partially correct, the better.
I think cve-rs is the perfect example of this. Its very existence proves that the borrow checker is already unsound, and with that, the very foundations of Rust's safety guarantees are currently flawed.
TypeScript is another good example, its type system has been repeatedly proven to be unsound, so it's also flawed.
But so what if it's flawed? Many smaller properties of these proofs still happen to hold, and they might prevent 90%+ of CVEs even as flawed as they are.
