2 ms·

The point I'm making is that, and this surprised me, the onus on soneone writing a module with unsafe code, to ensure it does not violate memory safety is much

The point I'm making is that, and this surprised me, the onus on soneone writing a module with unsafe code, to ensure it does not violate memory safety is much higher than I realized. It is not 'all rust' you must verify; just all rust that touches unsafe code. You might argue this is nothing new, and indeed if you read this comment thread you'll see the suggestion that the difference between verifying an entire module and verifying only the unsafe blocks in it is insignificant. My point is that there is at least an order of magnitude more safe code than unsafe code in an unsafe module, and I suspect it is not scrutinized nearly as much as the unsafe code. There are a lot of crates that use unsafe code in one form or another; and it troubles me (although no one else cares) that they are probably more dangerous than I realized. 'Just verify the unsafe blocks' is something I've literally heard people say.

dbaupp 11y ago
A lot of people care: e.g. the Rustonomicon[1] spends a lot of time caring about unsafe code (that is one of the main reasons for it to exist), and the massive RustBelt project[2], which Ralf (author of the blog post) is part of, is because people care. Even the lowest level developers (working on OSes) care about being very careful about how they use `unsafe`, e.g. [3]. One thing that some of us are hopeful will come out of RustBelt are more advanced `unsafe` checkers (i.e. some sort of proof assistant, possibly with lints built into the compiler). In any case, talking about "order of magnitude" misses the point somewhat: there might be a large amount more code, but a lot of it is trivial to verify, e.g. the declaration of a struct doesn't need any verification, nor do comments, and if T, the type with invariants, has no internal mutability (which is fairly typical for unsafe code outside std, IME), then any safe function that takes &T is automatically safe. [1]: http://doc.rust-lang.org/doc/stable/nomicon/ http://doc.rust-lang.org/doc/stable/nomicon/ [2]: http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ [3]: http://os.phil-opp.com/printing-to-screen.html http://os.phil-opp.com/printing-to-screen.html
- shadowmint 11y ago
  linked_list.rs once you strip the comments, struct defs, and whatnot out has 415 lines, of which 64 reside in unsafe blocks, 6x as much code to check. That's one trivial module. The piston modules and other c bindings have much worse ratios. When the amount of code that you have to verify manually jumps by 6x (or worse), that's surprising. I was surprised and troubled by that.
ralfj 11y ago
> There are a lot of crates that use unsafe code in one form or another; and it troubles me (although no one else cares) that they are probably more dangerous than I realized. Be careful here, module != crate. Most crates consist of many modules. Unsafe leaks into the module, not into the entire crate. > 'Just verify the unsafe blocks' is something I've literally heard people say. Well, so did I - that's why I wrote the post. > My point is that there is at least an order of magnitude more safe code than unsafe code in an unsafe module, and I suspect it is not scrutinized nearly as much as the unsafe code. I think many developers are aware that the safe code inside an "unsafe module" needs just as much scrutiny. The Rustonomicon documents this, now my post does, too. If you used to assume that only literally those blocks need verification - yes, you underestimated the effort. I think it is still manageable though, modules (like Java classes) are kind of a unit of programming that people can get in their head "as a whole". This is important not just for the safe/unsafe discussion, this is important because modules form the privacy boundary in Rust. Even when you only do safe stuff, you care about the abstraction boundary because you want to hide implementation details behind it.

dbaupp 11y ago

A lot of people care: e.g. the Rustonomicon[1] spends a lot of time caring about unsafe code (that is one of the main reasons for it to exist), and the massive RustBelt project[2], which Ralf (author of the blog post) is part of, is because people care. Even the lowest level developers (working on OSes) care about being very careful about how they use `unsafe`, e.g. [3]. One thing that some of us are hopeful will come out of RustBelt are more advanced `unsafe` checkers (i.e. some sort of proof assistant, possibly with lints built into the compiler). In any case, talking about "order of magnitude" misses the point somewhat: there might be a large amount more code, but a lot of it is trivial to verify, e.g. the declaration of a struct doesn't need any verification, nor do comments, and if T, the type with invariants, has no internal mutability (which is fairly typical for unsafe code outside std, IME), then any safe function that takes &T is automatically safe. [1]: http://doc.rust-lang.org/doc/stable/nomicon/ http://doc.rust-lang.org/doc/stable/nomicon/ [2]: http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ [3]: http://os.phil-opp.com/printing-to-screen.html http://os.phil-opp.com/printing-to-screen.html

shadowmint 11y ago
linked_list.rs once you strip the comments, struct defs, and whatnot out has 415 lines, of which 64 reside in unsafe blocks, 6x as much code to check. That's one trivial module. The piston modules and other c bindings have much worse ratios. When the amount of code that you have to verify manually jumps by 6x (or worse), that's surprising. I was surprised and troubled by that.

ralfj 11y ago

> There are a lot of crates that use unsafe code in one form or another; and it troubles me (although no one else cares) that they are probably more dangerous than I realized. Be careful here, module != crate. Most crates consist of many modules. Unsafe leaks into the module, not into the entire crate. > 'Just verify the unsafe blocks' is something I've literally heard people say. Well, so did I - that's why I wrote the post. > My point is that there is at least an order of magnitude more safe code than unsafe code in an unsafe module, and I suspect it is not scrutinized nearly as much as the unsafe code. I think many developers are aware that the safe code inside an "unsafe module" needs just as much scrutiny. The Rustonomicon documents this, now my post does, too. If you used to assume that only literally those blocks need verification - yes, you underestimated the effort. I think it is still manageable though, modules (like Java classes) are kind of a unit of programming that people can get in their head "as a whole". This is important not just for the safe/unsafe discussion, this is important because modules form the privacy boundary in Rust. Even when you only do safe stuff, you care about the abstraction boundary because you want to hide implementation details behind it.