4 ms·

No, it doesn't break the promises in any way. If all your code does potentially dangerous memory manipulation, then there's very little hope that there will eve

by ralfj 11y ago

No, it doesn't break the promises in any way. If all your code does potentially dangerous memory manipulation, then there's very little hope that there will ever be an automatic checker for the safety of your program. The promise of Rust rests on the assumption that most code is not like that. There are a few fundamental data structures that do crazy stuff, and okay, we have to use `unsafe` there - and if we want to have any formal guarantees, we have to do a formal proof. If are happy with less, we just manually audit that data structure extra carefully. We also put every such data structure in its own module, which carefully limits the amount of code that is exposed to this unsafety. However, most of the code will just use those data structures, and that's where Rust gives you a safety guarantee. Combing `Vec` and `HashMap` and all the other types from the standard library in any way you want, hammer them from multiple threads, send stuff across channels, whatever - you can do all of that safely, and if your code crashes, you don't have to look at all this code because you did not write `unsafe`, only the standard library did - and you are in a separate module. > Now its that you have to just make sure all your code is correct, not just the unsafe blocks. This is not correct. As I wrote in the post, you have to check all code within a module that contains `unsafe`. Most of the modules people write do not contain `unsafe`, and hence are not checked. I'd be curious to learn why you think this is the case.

shadowmint 11y ago
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.

by ralfj 11y ago

shadowmint 11y ago

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.