Tracking Issue for box_as_ptr

[RalfJung]

Feature gate: #![feature(box_as_ptr)]

This is a tracking issue for Box::as_ptr and Box::as_mut_ptr.

Public API

impl<T: ?Sized, A: Allocator> Box<T, A> {
    pub fn as_mut_ptr(b: &mut Self) -> *mut T;
    pub fn as_ptr(b: &Self) -> *const T;
}

Steps / History

• ACP: Add "as raw pointer" methods to Box libs-team#355
• Implementation: add Box::as_ptr and Box::as_mut_ptr methods #129091
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[orlp]

The current implementation of as_mut_ptr using addr_of_mut still suffers from the fact that moving the Box invalidates the pointer, which seems like a pretty big defect:

#![feature(box_as_ptr)]

fn main() {
    let mut b = Box::new(42);
    let p = Box::as_mut_ptr(&mut b);
    let _b2 = b;
    unsafe { *p = 0; };
}

error: Undefined Behavior: attempting deallocation using <1988> at alloc1024, but that tag does not exist in the borrow stack for this location
    --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1679:17
     |
1679 |                 self.1.deallocate(From::from(ptr.cast()), layout);
     |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempting deallocation using <1988> at alloc1024, but that tag does not exist in the borrow stack for this location
     |
     = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
     = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <1988> was created by a Unique retag at offsets [0x0..0x4]
    --> src/main.rs:6:15
     |
6    |     let _b2 = b;
     |               ^
help: <1988> was later invalidated at offsets [0x0..0x4] by a write access
    --> src/main.rs:7:14
     |
7    |     unsafe { *p = 0; };
     |              ^^^^^^
     = note: BACKTRACE (of the first span):
     = note: inside `<std::boxed::Box<i32> as std::ops::Drop>::drop` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1679:17: 1679:66
     = note: inside `std::ptr::drop_in_place::<std::boxed::Box<i32>> - shim(Some(std::boxed::Box<i32>))` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:574:1: 574:56
note: inside `main`
    --> src/main.rs:8:1
     |
8    | }
     | ^

[RalfJung]

Yes, that is currently expected. Moving the Box asserts full uniqueness of the Box, just like a mutable reference.

Also see the discussion at rust-lang/unsafe-code-guidelines#326.

[EFanZh]

Is Box::as_mut_ptr special? The follow code passes on Miri, but fails if I replace Box::as_mut_ptr with my_box_as_mut_ptr.

#![feature(box_as_ptr)]

use std::mem;

fn my_box_as_mut_ptr(b: &mut Box<i32>) -> *mut i32 {
    &raw mut **b
}

fn main() {
    let mut b = Box::new(7);
    let ptr = Box::as_mut_ptr(&mut b); // `my_box_as_mut_ptr` fails on Miri.

    mem::forget(b);

    unsafe {
        let b2 = Box::from_raw(ptr);

        dbg!(b2);
    }
}

[RalfJung]

It's not as_mut_ptr that is special but box-to-raw-pointer casts behave somewhat erratically in Miri -- and that's really hard to fix since we combined two features in Box that are pretty incompatible: aliasing requirements and custom allocators. Miri has a bunch of hacks to try and paper over that incompatibility as best as we can, but there are corner cases where that doesn't fully work and you found one of them.

Note that this affects only Stacked Borrows, not Tree Borrows.

[zachs18]

(Concretely, making my_box_as_mut_ptr generic over the Box's allocator (and enabling #![feature(allocator_api)]) makes Miri output the same for my_box_as_mut_ptr and Box::as_mut_ptr. playground link)

[RalfJung]

@golddranks this issue is about box_as_ptr; it doesn't seem like stabilizing that would help as then you still only get a raw pointer? So please open a new issue (you can open it in the Miri repo if you want, or otherwise ping me so I don't miss it).