4 ms·
The... memory safety? It will reliably blow up; that's quite an improvement already, when the alternative may be remote code execution. There's also of course
by Filligree 3y ago
The... memory safety? It will reliably blow up; that's quite an improvement already, when the alternative may be remote code execution.
There's also of course everything else, like the ergonomics, freedom from data races and so on, but I'll skip that.
- hgs3 3y agoWhether software blows up or not if an ID is "bad" depends on how it's written. Writing a token to a database without cleaning it up could lead to a security hole that has nothing to do with memory exploitation. I worry the fixation on memory is creating tunnel vision.
- fch42 3y agoHerb Sutter makes that point though somewhat hidden amongst all the apologetics... let's not forget there are security vulnerabilities that don't originate in memory access violations. "Easy" config mistakes, bad secrets protection, and human-factor-exposure are out there and don't depend on memory safety. Being humble about that would be only fair.
- deathanatos 3y agoI'm actually surprised their example wasn't the accidental use of a valid ID, not an invalid one. An invalid one is easily catchable, but an invalid one is akin to a bad pointer. The resulting behavior will slip by the Rust compiler, as we're basically using integers as pointers, and you can get all sorts of shadow-clone versions of malignant pointer behavior like use-after-free in such a scheme. That said … there are ways in Rust to do circular data structures that don't have the problems that using indexing into an array has, and are memory safe, and are within the safe subset of Rust. (E.g., Rc/Arc.)