5 ms·

It is in fact checked by both the compiler and the borrow checker. The only difference between safe and unsafe code is that the latter allows dereference of poi

It is in fact checked by both the compiler and the borrow checker. The only difference between safe and unsafe code is that the latter allows dereference of pointers and direct manipulation of memory, which may result in segfaults, memory leaks and data races.

electrograv 9y ago
The Rust compiler specifically aims to make it impossible to have segfaults, memory leaks, and data races — so to say unsafe code “is in fact checked” is at least a little misleading. The user still needs to do additional checking for memory errors in unsafe code.
- cwzwarich 9y ago
  Rust doesn't aim to make it impossible to have memory leaks: https://users.rust-lang.org/t/memory-leaks-are-memory-safe/5288 https://users.rust-lang.org/t/memory-leaks-are-memory-safe/5...
  - ben-schaaf 9y ago
    It at least eliminates what I'd estimate to be the most common cause of memory leaks (in C): missing a free. Which is the same guarantee that GCs provide.
    - oconnor663 9y ago
      The story is similar to C++. Almost all allocations are done by types that'll automatically call free in their destructors. But because there's no global GC, it's still possible to leak accidentally by creating a cycle in reference-counted smart pointers.
      - fnord123 9y ago
        There is still the other most common source of memory leaks: putting data into long living (e.g. 'static) hash tables and having no plan for pruning it.
solidsnack9000 9y ago
Maybe there is some checking but there is clearly somewhat less. This is in keeping with the general idiom (shared with Haskell and Swift, among others).
- steveklabnik 9y ago
  To be clear: unsafe Rust is a superset Of safe Rust. Every single safety check is still turned on in an unsafe block. However, that superset contains things that are not checked. This has no effect on any other code though; safe code with a superfluous unsafe block acts 100% exactly the same.

electrograv 9y ago

The Rust compiler specifically aims to make it impossible to have segfaults, memory leaks, and data races — so to say unsafe code “is in fact checked” is at least a little misleading. The user still needs to do additional checking for memory errors in unsafe code.

cwzwarich 9y ago
Rust doesn't aim to make it impossible to have memory leaks: https://users.rust-lang.org/t/memory-leaks-are-memory-safe/5288 https://users.rust-lang.org/t/memory-leaks-are-memory-safe/5...
- ben-schaaf 9y ago
  It at least eliminates what I'd estimate to be the most common cause of memory leaks (in C): missing a free. Which is the same guarantee that GCs provide.
  - oconnor663 9y ago
    The story is similar to C++. Almost all allocations are done by types that'll automatically call free in their destructors. But because there's no global GC, it's still possible to leak accidentally by creating a cycle in reference-counted smart pointers.
    - fnord123 9y ago
      There is still the other most common source of memory leaks: putting data into long living (e.g. 'static) hash tables and having no plan for pruning it.

solidsnack9000 9y ago

Maybe there is some checking but there is clearly somewhat less. This is in keeping with the general idiom (shared with Haskell and Swift, among others).

steveklabnik 9y ago
To be clear: unsafe Rust is a superset Of safe Rust. Every single safety check is still turned on in an unsafe block. However, that superset contains things that are not checked. This has no effect on any other code though; safe code with a superfluous unsafe block acts 100% exactly the same.