I've read about unsafe rust and that it does not disable the borrow checker. I thought that implies that I cannot have multiple mutable references to the same memory location. Even if I use unsafe blocks, but I think I've managed to get two mutable borrows of the same memory location: fn main() { …

[image] Sebi2020: which returns a reference which is dereferenced and then mutable referenced again. What's the difference? Why is it safe to do that in these functions but not in my code? It’s not forbidden to have two mutable references to the same target if one is a so-called “reborrow” of…

Consider the following small change to your code: (Playground) : #[inline(never)] fn set(p: &mut i32, q: &mut i32, o: i32, v: i32) { while *p == o { *q = v } } fn main() { let mut i1 = 1; let pointer = &mut i1; let pointer2: &mut i32; unsafe { pointer2 = &mut…

Ah, that makes sense, but I think the documentation is misleading.

I see the point (I think). The compiler assumes that *p never changes it's value because *p should be an exclusive mutable reference and therefore replaces the while loop with a loop {}. But I know that we have structures to create "multiple" mutable references by using constructs like Arc<Mutex<Box<…

This sounds a little bit like circular reasoning. If the compiler enforces me to always uphold the contract (it doesn't let me do unsound things) but allows me to do this in unsafe code while holding me responsible for not violating the contract at the same time, why should somebody use unsafe rust …

In an unsafe block you gain the following "superpowers": Dereference a raw pointer Call an unsafe function or method Access or modify a mutable static variable Implement an unsafe trait Access fields of unions All other rules of safe Rust are respected, but if you violate those rules via one of th…

Thank you, I will look at the posts. I'm just a little bit confused, because there is a split_at_mut(idx) function in the standard library and it looks like it violates these contracts, doing similiar things like my code, but it seems they do not break optimization: ... fn main() { let mut a = [1,2…

You need to look at the implementation of split_at_mut() to see why this is so: here and here . This is a good example of a programmer using unsafe correctly to perform a function too complex for the Rust compiler front-end to analyze while still complying with all the input requirements of the LLVM …

I've inspected the source and it takes &mut self pointer (the slice) converts it to a raw mutable pointer and calls: raw.rs - source Source of the Rust file `library/core/src/slice/raw.rs`. which returns a reference which is dereferenced and then mutable ref…

The soundness rules for Rust must always be followed, even in unsafe code. If they are not followed, your unsafe code is simply incorrect. However, there are cases where the borrow checker is too strict and rejects code that does follow the soundness rules. In the case of split_at_mut, it is correc…

Unsafe rust and the borrow checker (multiple mutable borrows)

help

TomP August 7, 2021, 4:05pm 11

Here are some answers that I've posted before in URLO, which address your last two posts, plus a great Quote of the Week from @alice.

Topic		Replies	Views
How unsafe is allowed in unsafe code? help	54	2580	July 30, 2023
Less strict borrowing on !Send+!Sync types?	19	724	June 24, 2024
Aliasing rules and mutable pointer dereference help	51	3637	August 7, 2023
Why can't you use a mutably borrowed value in-between mutable changes? help	35	5108	March 20, 2022
Alternative to mutability restriction in single-threaded contexts? help	20	3928	July 15, 2020

Unsafe rust and the borrow checker (multiple mutable borrows)

Related topics