Unsafe code review request for the inout crate

21

That was my intention, yes. The code you ask about started working when addr_of_mut was introduced to the language. I felt it is rather surprising for this code not to work, given that it is somewhat parallel to the following safe code:

fn main() {
    let mut x = 42;
    let y = &mut x;
    let z1 = y as &i32;
    let z2 = y as &i32;
    let _val = *z1;
    let _val = *z2;
    let _val = *z1;
    let _val = *z2;
}

In other words, mutable references can be turned into "shared things" multiple times and those shared things can coexist -- this is certainly true for shared references, and what you observed is that it is also true for "shared mutable raw pointers" aka *mut T.

2 Likes
22

Interesting point.

I just noticed that

fn main() {
    let mut x = 42;
    let y = &mut x;
    let z1 = addr_of_mut!(*y);
    let z2 = addr_of!(*y);
    unsafe { *z1 = 1 };
    unsafe { let _val = *z2; };
    unsafe { *z1 = 1 };
    unsafe { let _val = *z2; };
}

apparently isnā€™t allowed. Is there a reason for that? If it was allowed, could it be a good idea to make y as *const i32 equivalent to addr_of!(*y) and also allow the code

fn main() {
    let mut x = 42;
    let y = &mut x;
    let z1 = y as *mut i32;
    let z2 = y as *const i32;
    unsafe { *z1 = 1 };
    unsafe { let _val = *z2; };
    unsafe { *z1 = 1 };
    unsafe { let _val = *z2; };
}

for consistency? (Or maybe they already are equivalent, in which case Iā€™d ask to keep them equivalent and allow both versions.)

23

This is basically the previous point again: at the ref-to-raw boundary, addr_of!(*y) asks for a *const ptr to be crated, so this is a read-only ptr (SharedReadOnly in Stacked Borrows) that becomes invalid on the first write access.

They should be equivalent.

That would basically be

1 Like
24

Oh, rightā€¦ I didnā€™t even realize that in order for that code to work, y as *const i32 would need to create a mutable pointer (i.e. a pointer with write permissions). So consequentially then turning this *const i32 into *mut i32 and writing through it would also need to be allowed. Iā€™m not claiming that thatā€™s a bad consequence or that itā€™s a good consequence.

And thanks for the links. Iā€™m relieved that Iā€™m not imagining totally unreasonable features / changes here.

2 Likes
25

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.