Does this code violate the alias model?

[Luv-Ray]

come here from rust-lang/rust#130853
here is simplified code, which can be successfully run by miri

fn main() {
    let mut s = 0u8;
    let borrow = &raw mut s;
    unsafe {
        let const_borrow: *const *mut u8 = &raw const borrow;
        let x: &&u8 = &*const_borrow.cast::<&u8>();

        let y1 = **x; // get the value from `&&u8`
        *borrow = 1; // modify `s`
        let y2 = **x; // and the value changed
        assert!(y1 != y2);
    }
}

Does this code conform to the alias model? Or miri has some issues with handling cast?

[saethlin]

This code seems perfectly valid to me. It's confusing because of the way the source is written, but I think that's it. Operationally it is much simpler. Roughly line-by-line:

We create a raw pointer which definitely has read permission to s, but call it borrow.
Then we create const_borrow which is a raw pointer to that pointer, and use a combination of casting and reborrowing to turn it into a &&u8. So this x is not allowed to mutate const_borrow, and if we read through it, the reference that we get back will not be allowed to mutate s.
Then we use x to read const_borrow, which is the same as transmuting const_borrow to a shared reference (because of the type of x), then reading through that.
Then we write through borrow. The only possible hazard here is that we could invalidate any other pointers to s with this operation. But there aren't any!
Then we read again. Which is still fine.

Perhaps what is tripping you up is that the aliasing model does not follow pointer indirection? If you have a & *mut u8 (a shared reference to a pointer to a u8), that shared reference isn't allowed to mutate the pointer. But it is valid to use the shared reference to read the pointer, and if the pointer has write permissions, that pointer can be written through.

[oxalica]

If you have a & *mut u8 (a shared reference to a pointer to a u8), that shared reference isn't allowed to mutate the pointer. But it is valid to use the shared reference to read the pointer, and if the pointer has write permissions, that pointer can be written through.

The problem is that, from callee's perspective, it's just a &&u8 where u8: Freeze. I expect the compiler to be able to optimize out multiple reads. Otherwise, it would be so unfortunate, since an indirection &&i32 completely loses the ability to be immutable. Having double references as function arguments is pretty common in Rust via slices like &[&str] or structs like &S with struct S<'a> { s: &'a str }. We'll be forced to re-read all these references after any function call in the function, even if we are having a parent immutable reference.

[saethlin]

I've explained how the above code works in Stacked Borrows, and that the fact that this passes is not a bug in Miri. Now you're trying to argue that this has optimization value and should be UB, which is a completely different discussion. This is related to but probably not exactly the same as rust-lang/unsafe-code-guidelines#412. You should try to argue for this optimization in an issue on that repo.