And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?
Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.
Accessing a union that’s in an invalid state is also a big problem.
Use after free… Maybe?
Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.
Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).
A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.
What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using std::unique_ptr. In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block
In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block
Which is what I said, this is about the default.
My issue is not that I don’t understand Rust provides static guarantees. My issue is that you raised a comparison between unsafe Rust and C++ code. In that comparison, you’re basically saying “writing an entire program in a rust unsafe block would be better than writing an entire program in C++” and I think that is very wrong.
Rust unsafe is not better than normal C++ while following best practices for maintaining memory safety.
I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.
I would still like to take a moment to answer your specific questions more directly:
And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?
I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.
Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.
I think that’s only half of the issue, with the other half indeed being use after free. After all, using a reference isn’t much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there’s a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.
Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.
Thread safe code is also the issue. The reason people don’t have to run from Java is because data races there don’t escalate to memory unsafety; they’re just caught as “ordinary” exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.
Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).
It is indeed a dangerous subset, but as I mentioned elsewhere, Rust’s borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an unsafe block. It is only when you explicitly use the unsafe features that you’re on your own when it comes to safety.
A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.
They indeed avoid some of the issues, but notably don’t protect against use after free at all. And take std::vector as an example:
std::vector v;
v[2]; // out-of-bounds access
vs.
unsafe {
letv = Vec::new();
v[2]; // panic
}
Even wrapped in unsafe, the Rust equivalents are still safer.
And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?
Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.
Accessing a union that’s in an invalid state is also a big problem.
Use after free… Maybe?
Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.
Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).
A lot of these issues can be avoided in C++ by just using existing types like
std::variant,std::unique_ptr,std::shared_ptr,std::array, andstd::vector(with theatbased accessor) instead of lower level constructs.What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using
std::unique_ptr. In Rust however you must sign a contact (usingunsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of blockWhich is what I said, this is about the default.
My issue is not that I don’t understand Rust provides static guarantees. My issue is that you raised a comparison between unsafe Rust and C++ code. In that comparison, you’re basically saying “writing an entire program in a rust unsafe block would be better than writing an entire program in C++” and I think that is very wrong.
Rust unsafe is not better than normal C++ while following best practices for maintaining memory safety.
I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.
I would still like to take a moment to answer your specific questions more directly:
I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.
I think that’s only half of the issue, with the other half indeed being use after free. After all, using a reference isn’t much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there’s a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.
Thread safe code is also the issue. The reason people don’t have to run from Java is because data races there don’t escalate to memory unsafety; they’re just caught as “ordinary” exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.
It is indeed a dangerous subset, but as I mentioned elsewhere, Rust’s borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an
unsafeblock. It is only when you explicitly use the unsafe features that you’re on your own when it comes to safety.They indeed avoid some of the issues, but notably don’t protect against use after free at all. And take
std::vectoras an example:std::vector v; v[2]; // out-of-bounds accessvs.
unsafe { let v = Vec::new(); v[2]; // panic }Even wrapped in
unsafe, the Rust equivalents are still safer.