4 ms·

Well, given the most common refute of my concerns is 'you just have to make sure your unsafe blocks are verified to be correct', and the point of this article,

Well, given the most common refute of my concerns is 'you just have to make sure your unsafe blocks are verified to be correct', and the point of this article, is explicitly that this isnt the case... Now its that you have to just make sure all your code is correct, not just the unsafe blocks. /me shrugs I think thats lame, and breaks the promises rust is trying to make about writing safe secure software. If safe code may not be safe, whats the point of it at all. You, are of course welcome to your own oppinion.

kibwen 11y ago
> Now its that you have to just make sure all your code is > correct, not just the unsafe blocks. You appear to be misunderstanding the article, which likely explains all the downvotes. Rust keeps you from doing memory-unsafe operations unless you use an `unsafe` block somewhere. Once you do, then it is your duty to ensure that those `unsafe` blocks don't cause memory unsafety, regardless of what the rest of your program does. Following from that, if the correctness of your `unsafe` block relies on invariants in your data, then it is your duty to keep your data private so that those invariants cannot be broken by consumers (or alternatively, provide safe accessor functions that allow consumers to fiddle with things while performing runtime checks to ensure invariants are upheld).
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.
dbaupp 11y ago
As people keep saying, one only has to verify functions that can break invariants, e.g. if you define a type that has invariants needed by `unsafe` blocks, then one has to take a close look at any functions that can modify its internals (i.e. things inside the module the type is defined). Functions that can't break these invariants because they don't have access to the internals of a type do not need to be checked: they can be assumed safe. > Well, given the most common refute of my concerns is 'you just have to make sure your unsafe blocks are verified to be correct', and the point of this article, is explicitly that this isnt the case... And, as my comment says twice, my point is just that the two cases are not very different: verifying all unsafe blocks and verifying the modules that contain `unsafe` aren't that different.

kibwen 11y ago

> Now its that you have to just make sure all your code is > correct, not just the unsafe blocks. You appear to be misunderstanding the article, which likely explains all the downvotes. Rust keeps you from doing memory-unsafe operations unless you use an `unsafe` block somewhere. Once you do, then it is your duty to ensure that those `unsafe` blocks don't cause memory unsafety, regardless of what the rest of your program does. Following from that, if the correctness of your `unsafe` block relies on invariants in your data, then it is your duty to keep your data private so that those invariants cannot be broken by consumers (or alternatively, provide safe accessor functions that allow consumers to fiddle with things while performing runtime checks to ensure invariants are upheld).

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.

dbaupp 11y ago

As people keep saying, one only has to verify functions that can break invariants, e.g. if you define a type that has invariants needed by `unsafe` blocks, then one has to take a close look at any functions that can modify its internals (i.e. things inside the module the type is defined). Functions that can't break these invariants because they don't have access to the internals of a type do not need to be checked: they can be assumed safe. > Well, given the most common refute of my concerns is 'you just have to make sure your unsafe blocks are verified to be correct', and the point of this article, is explicitly that this isnt the case... And, as my comment says twice, my point is just that the two cases are not very different: verifying all unsafe blocks and verifying the modules that contain `unsafe` aren't that different.