5 ms·

This is not really true. You have to uphold those guarantees yourself. With unsafe preconditions, if you don't, the code will still crash loudly (which is bette

This is not really true. You have to uphold those guarantees yourself. With unsafe preconditions, if you don't, the code will still crash loudly (which is better than undefined behaviour).

littlestymaar 2y ago
With unsafe you get exactly the same kind of semantics as C, if you don't uphold the invariant the unsafe functions expect, you end up with UB exactly like in C. If you want a clean crash instead on indeterministic behavior, you need to use assert like in C, but it won't save you from compiler optimization removing checks that are deemed useless (again, exactly like in C).
- lenkite 2y ago
  > With unsafe you get exactly the same kind of semantics as C People seem to disagree. Unsafe Rust Is Harder Than C https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41944121 https://news.ycombinator.com/item?id=41944121
  - kibwen 2y ago
    Using references in unsafe Rust is harder than using raw pointers in C. Using raw pointers in unsafe Rust is easier than using raw pointers in C. The solution is to not manipulate references in unsafe code. The problem is that in old versions of Rust this was tricky. Modern versions of Rust have addressed this by adding first-class facilities for producing pointers without needing temporary references: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#native-syntax-for-creating-a-raw-pointer https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#nativ...
- selfmodruntime 2y ago
  > With unsafe you get exactly the same kind of semantics as C, if you don't uphold the invariant the unsafe functions expect, you end up with UB exactly like in C. This is not exactly true. Even in production code, unsafe preconditions check if you violate these rules. Here: https://doc.rust-lang.org/core/macro.assert_unsafe_precondition.html https://doc.rust-lang.org/core/macro.assert_unsafe_precondit... And here: https://google.github.io/comprehensive-rust/unsafe-rust/unsafe.html https://google.github.io/comprehensive-rust/unsafe-rust/unsa...
  - bangaladore 2y ago
    Quoted from your link > Safe Rust: memory safe, no undefined behavior possible. Unsafe Rust: can trigger undefined behavior if preconditions are violated. So Unsafe Rust from a UB perspective is no different than C/C++. If preconditions are violated, UB can occur, affecting anywhere in the program. Its unclear how the compiler could check anything about preconditions in a block explicitly used to say that the developer is the one upholding the preconditions.
    - randomNumber7 2y ago
      The rust compiler was written by chuck norris.
    - selfmodruntime 2y ago
      > So Unsafe Rust from a UB perspective is no different than C/C++. If preconditions are violated, UB can occur Only if you actively disable panics being triggered if unsafe preconditions are triggered. In most code, the program will crash instead. Enabling default panic on up violation in production code was done last year, IIRC. > Its unclear how the compiler could check anything about preconditions It can't. This is done at runtime, by default and without manually needed programmer interaction. You can see an example of this in the `ptr`module, here: https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1071 https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1071 Some are only enabled for `debug_assert` (which is enabled by default), see `ptr::read`, here: https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1370 https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1370
      - bangaladore 2y ago
        These seem to be beta features. But in any case it seems like its just doing some number of asserts to validate some preconditions. However, even at runtime it can't do anything to say if (excuse the C pseudocode) *(uint32_t*)0x1C00 = 0xFE is a valid memory operations. On some systems, in some cases it might be.
        2y ago

This is not really true. You have to uphold those guarantees yourself. With unsafe preconditions, if you don't, the code will still crash loudly (which is better than undefined behaviour).

littlestymaar 2y ago

With unsafe you get exactly the same kind of semantics as C, if you don't uphold the invariant the unsafe functions expect, you end up with UB exactly like in C. If you want a clean crash instead on indeterministic behavior, you need to use assert like in C, but it won't save you from compiler optimization removing checks that are deemed useless (again, exactly like in C).

lenkite 2y ago
> With unsafe you get exactly the same kind of semantics as C People seem to disagree. Unsafe Rust Is Harder Than C https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41944121 https://news.ycombinator.com/item?id=41944121
- kibwen 2y ago
  Using references in unsafe Rust is harder than using raw pointers in C. Using raw pointers in unsafe Rust is easier than using raw pointers in C. The solution is to not manipulate references in unsafe code. The problem is that in old versions of Rust this was tricky. Modern versions of Rust have addressed this by adding first-class facilities for producing pointers without needing temporary references: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#native-syntax-for-creating-a-raw-pointer https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#nativ...
selfmodruntime 2y ago
> With unsafe you get exactly the same kind of semantics as C, if you don't uphold the invariant the unsafe functions expect, you end up with UB exactly like in C. This is not exactly true. Even in production code, unsafe preconditions check if you violate these rules. Here: https://doc.rust-lang.org/core/macro.assert_unsafe_precondition.html https://doc.rust-lang.org/core/macro.assert_unsafe_precondit... And here: https://google.github.io/comprehensive-rust/unsafe-rust/unsafe.html https://google.github.io/comprehensive-rust/unsafe-rust/unsa...
- bangaladore 2y ago
  Quoted from your link > Safe Rust: memory safe, no undefined behavior possible. Unsafe Rust: can trigger undefined behavior if preconditions are violated. So Unsafe Rust from a UB perspective is no different than C/C++. If preconditions are violated, UB can occur, affecting anywhere in the program. Its unclear how the compiler could check anything about preconditions in a block explicitly used to say that the developer is the one upholding the preconditions.
  - randomNumber7 2y ago
    The rust compiler was written by chuck norris.
  - selfmodruntime 2y ago
    > So Unsafe Rust from a UB perspective is no different than C/C++. If preconditions are violated, UB can occur Only if you actively disable panics being triggered if unsafe preconditions are triggered. In most code, the program will crash instead. Enabling default panic on up violation in production code was done last year, IIRC. > Its unclear how the compiler could check anything about preconditions It can't. This is done at runtime, by default and without manually needed programmer interaction. You can see an example of this in the `ptr`module, here: https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1071 https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1071 Some are only enabled for `debug_assert` (which is enabled by default), see `ptr::read`, here: https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1370 https://doc.rust-lang.org/beta/src/core/ptr/mod.rs.html#1370
    - bangaladore 2y ago
      These seem to be beta features. But in any case it seems like its just doing some number of asserts to validate some preconditions. However, even at runtime it can't do anything to say if (excuse the C pseudocode) *(uint32_t*)0x1C00 = 0xFE is a valid memory operations. On some systems, in some cases it might be.
      - 2y ago