6 ms·

Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advant

by bitwize 11mo ago

Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.

noosphr 11mo ago
The safest computer is a rock. The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow. Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.
- josephg 11mo ago
  > when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. Safe rust isn't slow like Python, Go or Fil-C. It gets compiled to normal native code just like C and C++. It generally runs just as fast as C. At least, almost all the time. Arrays have runtime bounds checks. And ... thats about it. > The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow. Nah. Most rust is safe rust. Even in the kernel, not much code actually interacts directly with raw hardware. The argument in favour of moving to rust isn't that it will remove 100% of memory safety bugs. Just that it'll hopefully remove most of them.
uecker 11mo ago
IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to find as a keyword, but I do not think this is a fundamental advantage, especially in projects where you have a lot of such "unsafe" blocks.
- Xylakant 11mo ago
  > Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.
  - uecker 11mo ago
    First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement. Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety, you need to review all other code anyway! But even then, it is also not true that only the code marked with "unsafe" is relevant. This is major myth. The "unsafe" code can cause UB outside "unsafe" and logic bugs outside "unsafe" can cause bugs unsafe. This does not perfectly decouple if you Rust repeat this nonsense over and over again. Don't get me wrong, I think the unsafe keyword is good idea. But the magical powers Rust fans attribute to it and the "SAFETY" comment they put next to it tells me they are a bit delusional.
    - unrealhoang 11mo ago
      > logic bugs outside "unsafe" can cause bugs unsafe. This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build. The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".
      - queejjd 11mo ago
        Two questions: Why was the fix to this unsafe memory safety bug [0] only changes to code outside of unsafe Rust blocks?[1][2] Why does the Rustonomicon[3] say the following? > This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against. It has to trust the capacity field because there's no way to verify it. > Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy. [0] https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3428831264096d32f830a7fcfc7885dd263e511a https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/android/binder/node.rs?id=3428831264096d32f830a7fcfc7885dd263e511a#n536 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [3] https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://doc.rust-lang.org/nomicon/working-with-unsafe.html

by bitwize 11mo ago

noosphr 11mo ago

The safest computer is a rock. The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow. Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.

josephg 11mo ago
> when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. Safe rust isn't slow like Python, Go or Fil-C. It gets compiled to normal native code just like C and C++. It generally runs just as fast as C. At least, almost all the time. Arrays have runtime bounds checks. And ... thats about it. > The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow. Nah. Most rust is safe rust. Even in the kernel, not much code actually interacts directly with raw hardware. The argument in favour of moving to rust isn't that it will remove 100% of memory safety bugs. Just that it'll hopefully remove most of them.

uecker 11mo ago

IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to find as a keyword, but I do not think this is a fundamental advantage, especially in projects where you have a lot of such "unsafe" blocks.

Xylakant 11mo ago
> Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.
- uecker 11mo ago
  First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement. Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety, you need to review all other code anyway! But even then, it is also not true that only the code marked with "unsafe" is relevant. This is major myth. The "unsafe" code can cause UB outside "unsafe" and logic bugs outside "unsafe" can cause bugs unsafe. This does not perfectly decouple if you Rust repeat this nonsense over and over again. Don't get me wrong, I think the unsafe keyword is good idea. But the magical powers Rust fans attribute to it and the "SAFETY" comment they put next to it tells me they are a bit delusional.
  - unrealhoang 11mo ago
    > logic bugs outside "unsafe" can cause bugs unsafe. This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build. The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".
    - queejjd 11mo ago
      Two questions: Why was the fix to this unsafe memory safety bug [0] only changes to code outside of unsafe Rust blocks?[1][2] Why does the Rustonomicon[3] say the following? > This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against. It has to trust the capacity field because there's no way to verify it. > Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy. [0] https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3428831264096d32f830a7fcfc7885dd263e511a https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/android/binder/node.rs?id=3428831264096d32f830a7fcfc7885dd263e511a#n536 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [3] https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://doc.rust-lang.org/nomicon/working-with-unsafe.html