And are also woefully insufficient as proven in most sanitized & linted & fuzz-tested programs in existence (browsers and operating systems).
replyCompared to what? CVE-2025-68260?
replyCompared to, for example, 5 million Rust lines in Android, I'd say.
replyYeah, the anti-Rust crowd seems to just hate Rust and completely ignore all the empirical evidence that professional C++, even using all the TSAN, ASAN etc still has ~10-100x the memory safety issues of Rust without any of that. I think they think “oh - use after free and out of bounds are trivial to solve” and ignore the enormously meaningful order of magnitude harder thread safety. Not to mention that sanitizers are only effective at validating the code paths exercised within the test suite. Production manages to test all the things your test suite missed. The Rust compiler verifies stricter properties about your program proof being correct in all cases (within the bounds of its own correctness of course, but that’s higher than all other code combined).
reply> “oh - use after free and out of bounds are trivial to solve” and ignore the enormously meaningful order of magnitude harder thread safety
replyThis is what advocates of Rust are guilty of and CVE-2025-68260 is an example of it. Ultimately TSAN and KTSAN exist for a reason, and rust devs should learn how to use them effectively.
I'm not saying don't use sanitizers. I'm saying that even without sanitizers you're better. Also, this CVE isn't strictly a Rust problem - it's a problem creating safe boundaries around unsafe C code which was difficult even for the Rust standard library to suss out and even harder in kernel land where the rules are often not even documented. It'll take time but I don't see how this is an inditement. I can point to the myriad of CVEs the kernel has in C code regardless of sanitizers being used - what consistent and equal standard are you upholding those lines of code to.
reply