> Huh, are you really trying to say unsafe Rust is safe?
I'm unclear what part of my comment would lead someone to such an extreme conclusion. As mentioned, the `unsafe` keyword is used to unlock new operations and create new safety invariants that must be manually upheld. Naturally, failure to manually uphold those new invariants would lead to memory unsafety. But an `unsafe` block introduces no unsafety by itself. Which is to say, if you take a working Rust program with no unsafe blocks, and then wrap the body of `main` in an unsafe block, this is a no-op; it does nothing.
> By this logic, C is safe, it also just has "safety invariants that must be manually upheld."
Certainly, this is true, and I'm not sure why anyone would think otherwise. The problem is not that it is theoretically impossible to write correct C; rather the problem is that it is empirically infeasible to do so at scale. By locking unsafe operations behind an unsafe block, Rust attempts to make it feasible to identify the areas of most concern in a codebase and focus attention on proving those areas correct manually.
> Unsafe Rust is even less safe than C because the rules that must be manually upheld are stricter.
Unfortunately this is another misconception, although it's understandable why one would think this. The rules for raw pointers in Rust are less strict than the rules for raw pointers in C, which is to say, manipulating raw pointers in Rust is safer than doing the same in C. The misconception here comes from the conflation of raw pointers with Rust's references, which do have more safety invariants to uphold, and for several years there were footguns to be found here due to language-level deficiences WRT the inability to avoid creating temporary references when working with uninitialized or unaligned memory. The good news is that this was addressed with the addition of std::mem::addr_of in Rust 1.51.
> For example in C you can create an invalid pointer and it's fine as long as you don't access it.
Unfortunately, this is incorrect, though it illustrates why raw pointer manipulation is more fraught in C than it is in Rust. In C, using pointer arithmetic to cause a pointer to point outside the bounds of an array (save for one element past the end) is undefined behavior, even if you never dereference that pointer. In contrast, this is not undefined behavior in Rust. As another example, comparing pointers from two different allocations with less-than/greater-than is undefined behavior in C, but this is not undefined behavior in Rust.
> There's no common misconception here. I think you're misunderstanding the quoted comment due to being overly pedantic.
I have seen this misconception arise regularly for years. If this is not what the parent commenter intended, then I apologize for misreading it. At the same time, I don't regret clarifying Rust's semantics for the benefit of people who may be unfamiliar with them. Surely it benefits us all to learn from each other.
I'm unclear what part of my comment would lead someone to such an extreme conclusion. As mentioned, the `unsafe` keyword is used to unlock new operations and create new safety invariants that must be manually upheld. Naturally, failure to manually uphold those new invariants would lead to memory unsafety. But an `unsafe` block introduces no unsafety by itself. Which is to say, if you take a working Rust program with no unsafe blocks, and then wrap the body of `main` in an unsafe block, this is a no-op; it does nothing.
> By this logic, C is safe, it also just has "safety invariants that must be manually upheld."
Certainly, this is true, and I'm not sure why anyone would think otherwise. The problem is not that it is theoretically impossible to write correct C; rather the problem is that it is empirically infeasible to do so at scale. By locking unsafe operations behind an unsafe block, Rust attempts to make it feasible to identify the areas of most concern in a codebase and focus attention on proving those areas correct manually.
> Unsafe Rust is even less safe than C because the rules that must be manually upheld are stricter.
Unfortunately this is another misconception, although it's understandable why one would think this. The rules for raw pointers in Rust are less strict than the rules for raw pointers in C, which is to say, manipulating raw pointers in Rust is safer than doing the same in C. The misconception here comes from the conflation of raw pointers with Rust's references, which do have more safety invariants to uphold, and for several years there were footguns to be found here due to language-level deficiences WRT the inability to avoid creating temporary references when working with uninitialized or unaligned memory. The good news is that this was addressed with the addition of std::mem::addr_of in Rust 1.51.
> For example in C you can create an invalid pointer and it's fine as long as you don't access it.
Unfortunately, this is incorrect, though it illustrates why raw pointer manipulation is more fraught in C than it is in Rust. In C, using pointer arithmetic to cause a pointer to point outside the bounds of an array (save for one element past the end) is undefined behavior, even if you never dereference that pointer. In contrast, this is not undefined behavior in Rust. As another example, comparing pointers from two different allocations with less-than/greater-than is undefined behavior in C, but this is not undefined behavior in Rust.
> There's no common misconception here. I think you're misunderstanding the quoted comment due to being overly pedantic.
I have seen this misconception arise regularly for years. If this is not what the parent commenter intended, then I apologize for misreading it. At the same time, I don't regret clarifying Rust's semantics for the benefit of people who may be unfamiliar with them. Surely it benefits us all to learn from each other.