4 ms·

To quote the Rust book (https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html): In addition, unsafe

by akx 2y ago

To quote the Rust book (https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html): In addition, unsafe does not mean the code inside the block is necessarily dangerous or that it will definitely have memory safety problems: the intent is that as the programmer, you’ll ensure the code inside an unsafe block will access memory in a valid way. Since you say you already know that much Rust, you can be that programmer!

silisili 2y ago
I feel like C programmers had the same idea, and well, we see how that works out in practice.
- dijit 2y ago
  the problem in those cases is that C can’t help but be unsafe always. People can write memory safe code, just not 100% of the time.
- sunshowers 2y ago
  No, C lacks encapsulation of unsafe code. This is very important. Encapsulation is the only way to scale local reasoning into global correctness.
  - chillingeffect 2y ago
    Eh. Good C programmers know what's safe and what's not. Often comments call out sketchy stuff. Just because it's not a language keyword, doesnt mean it's not called out. Bad C programmers though? Their stuff is more dangerous and they don't know when and don't call it out and should probably stick to Rust.
    - sunshowers 2y ago
      No, it's been proven over and over that simply knowing invariants is not enough, in long-term projects built by large teams where team members change over time. Even the most experienced C developers are going to fail every so often. You need tooling that automates those invariants, and you need that tooling to fail closed. I take a hard line on this stuff because we can either keep repeating the fundamental mistake of believing things like "willpower" to write correct code are real, or we can move on and adopt better tooling.
    - fasterthanlime 2y ago
      True! Only, Good C programmers don’t exist.
    - hyperbrainer 2y ago
      And where can I find this mythical "Good C programmer"?
    - 12_throw_away 2y ago
      Dunno why this is being downvoted, obviously no true Scotsman would ever use memory after freeing it.
  - DannyBee 2y ago
    Hard disagree - if you violate the invariants in Rust unsafe code, you can cause global problems with local code. You can cause use-after-free, and other borrow checker violations, with incorrect unsafe code. Nothing will flag it, you will have no idea which unsafe code block is causing the isue, debugging will be hard. I have no idea what your definition of encapsulation is, but mine is not this. It's really only encapsulated in the sense that if you have a finite and small set of unsafe blocks, you can audit them easier and be pretty sure that your memory safety bugs are in there. This reality really doesn't exist much anymore because of how much unsafe is often ued, and since you you have to audit all of them, whether they come from a library or not, it's not as useful to claim encapsulation as one thinks. I do agree in theory that unsafe encapsulation was supposed to be a thing, but i think it's crazy at this point to not admit that unsafe blocks turned out to easily have much more global effects than people expected, in many more cases, and are used more readily than expected. Saying "scaling reasoning" also implies someone reasoned about it, or can reason about it. But the practical problem is the same in both cases - someone got the reasoning wrong and nothing flagged it. Wanna go search github for how many super popular libraries using unsafe had global correctness issues due to local unsafe blocks that a human reasoned incorrectly about, but something like miri found? Most of that unsafety that turned out to be buggy also was done for (unnecessary) performance reasons. What you are saying is just something people tell themselves to make them feel okay about using unsafe all over the place. If you want global correctness, something has to verify it, ideally not-human. In the end, the thing C lacks is tools like miri that can be used practically with low false-positives, not "encapsulation" of unsafe code, which is trivially easy to perform in C. Let's not kid ourselves here and end up building an ecosystem that is just as bad as the C one, but our egos refuse to allow us to admit it. We should instead admit our problems and try to improve. Unsafe also has legitimate use cases in rust, for sure - but most unsafe code i look at does not need to exist, and is not better than unsafe C. I'll give you an example: There are entire popular embedded bluetooth stacks in rust using unsafe global mutable variables and raw pointers and ..., across threads, for everything. This is not better than the C equivalent - in fact it's worse, because users think it is safe and it's very not. At least nobody thinks the C version is safe. It will often therefore be shoved in a binary that is highly sandboxed/restricted/etc. It would be one thing if this was in the process of being ported/translated from C. But it's not. Using intrinsics that require alignment and the API was still being worked on - probably a reasonable use of unsafe (though still easy to cause global problems like buffer overflows if you screwed up the alignment) The bluetooth example - unreasonable.
- rcxdude 2y ago
  C's safe subset is so small as to be basically useless, and especially it's impossible to encapsulate behavior into a safe interface, in fact it's fairly easy in C to make an interface which is impossible to use correctly (gets() and the like).

by akx 2y ago

silisili 2y ago

I feel like C programmers had the same idea, and well, we see how that works out in practice.

dijit 2y ago
the problem in those cases is that C can’t help but be unsafe always. People can write memory safe code, just not 100% of the time.
sunshowers 2y ago
No, C lacks encapsulation of unsafe code. This is very important. Encapsulation is the only way to scale local reasoning into global correctness.
- chillingeffect 2y ago
  Eh. Good C programmers know what's safe and what's not. Often comments call out sketchy stuff. Just because it's not a language keyword, doesnt mean it's not called out. Bad C programmers though? Their stuff is more dangerous and they don't know when and don't call it out and should probably stick to Rust.
  - sunshowers 2y ago
    No, it's been proven over and over that simply knowing invariants is not enough, in long-term projects built by large teams where team members change over time. Even the most experienced C developers are going to fail every so often. You need tooling that automates those invariants, and you need that tooling to fail closed. I take a hard line on this stuff because we can either keep repeating the fundamental mistake of believing things like "willpower" to write correct code are real, or we can move on and adopt better tooling.
  - fasterthanlime 2y ago
    True! Only, Good C programmers don’t exist.
  - hyperbrainer 2y ago
    And where can I find this mythical "Good C programmer"?
  - 12_throw_away 2y ago
    Dunno why this is being downvoted, obviously no true Scotsman would ever use memory after freeing it.
- DannyBee 2y ago
  Hard disagree - if you violate the invariants in Rust unsafe code, you can cause global problems with local code. You can cause use-after-free, and other borrow checker violations, with incorrect unsafe code. Nothing will flag it, you will have no idea which unsafe code block is causing the isue, debugging will be hard. I have no idea what your definition of encapsulation is, but mine is not this. It's really only encapsulated in the sense that if you have a finite and small set of unsafe blocks, you can audit them easier and be pretty sure that your memory safety bugs are in there. This reality really doesn't exist much anymore because of how much unsafe is often ued, and since you you have to audit all of them, whether they come from a library or not, it's not as useful to claim encapsulation as one thinks. I do agree in theory that unsafe encapsulation was supposed to be a thing, but i think it's crazy at this point to not admit that unsafe blocks turned out to easily have much more global effects than people expected, in many more cases, and are used more readily than expected. Saying "scaling reasoning" also implies someone reasoned about it, or can reason about it. But the practical problem is the same in both cases - someone got the reasoning wrong and nothing flagged it. Wanna go search github for how many super popular libraries using unsafe had global correctness issues due to local unsafe blocks that a human reasoned incorrectly about, but something like miri found? Most of that unsafety that turned out to be buggy also was done for (unnecessary) performance reasons. What you are saying is just something people tell themselves to make them feel okay about using unsafe all over the place. If you want global correctness, something has to verify it, ideally not-human. In the end, the thing C lacks is tools like miri that can be used practically with low false-positives, not "encapsulation" of unsafe code, which is trivially easy to perform in C. Let's not kid ourselves here and end up building an ecosystem that is just as bad as the C one, but our egos refuse to allow us to admit it. We should instead admit our problems and try to improve. Unsafe also has legitimate use cases in rust, for sure - but most unsafe code i look at does not need to exist, and is not better than unsafe C. I'll give you an example: There are entire popular embedded bluetooth stacks in rust using unsafe global mutable variables and raw pointers and ..., across threads, for everything. This is not better than the C equivalent - in fact it's worse, because users think it is safe and it's very not. At least nobody thinks the C version is safe. It will often therefore be shoved in a binary that is highly sandboxed/restricted/etc. It would be one thing if this was in the process of being ported/translated from C. But it's not. Using intrinsics that require alignment and the API was still being worked on - probably a reasonable use of unsafe (though still easy to cause global problems like buffer overflows if you screwed up the alignment) The bluetooth example - unreasonable.
rcxdude 2y ago
C's safe subset is so small as to be basically useless, and especially it's impossible to encapsulate behavior into a safe interface, in fact it's fairly easy in C to make an interface which is impossible to use correctly (gets() and the like).