Stacked Borrows: raw pointer usable only for T too strict?

Currently, the following is illegal according to Stacked Borrows:

let val = [1u8, 2];
let ptr = &val[0] as *const u8;
let _val = unsafe { *ptr.add(1) };

The problem is that the cast to *const u8 creates a raw pointer that may only be used for the u8 it points to, not anything else. The most common case is to do &slice[0] as *const _ instead of slice.as_ptr().

This has lead to problems:

Maybe this is too restrictive and raw pointers should be allowed to access their "surroundings"? I am not sure what exactly that would look like though. It would probably require having the raw pointer fully inherit all permissions from the reference it is created from.

I'll use this issue to collect such cases.

This is also a problem in Rc::into_raw/Rc::from_raw:

    pub fn into_raw(this: Self) -> *const T {
        let ptr: *const T = &*this;
        mem::forget(this);
        ptr
    }

ptr may only be used to access the T part of the RcBox<T>, but if later used with from_raw it is used for the entire Rc. Fixing this is not even possible without rust-lang/rfcs#2582.

Auto merge of #80 - RalfJung:raw, r=Amanieu

@Amanieu

This also came up in Gilnaa/memoffset#21, where @Amanieu proposed an container_of! macro that computes the address of a struct given the address of one of its fields.

@Amanieu

@Amanieu the problem with code like this

struct Pair { f1: u16, f2: u16 };

let p = Pair { f1: 2, f2: 3 };
let c = container_of!(&p.f1, Pair, f1);
let _val = c.f2;

arises when you imagine splitting it across several functions:

struct Pair { f1: u16, f2: u16 };

let p = Pair { f1: 2, f2: 3 };
foo(&p.f1);
p.f2 = 4;

We want the compiler to be able to move the assignment to f2 up across the call to foo. But if foo is allowed to use container_of! and then read f2, that is no longer possible.

So, I think there is a real conflict here between being able to bound the effects of a call like foo(&p.f1), and allowing container_of!.

How does this work with [T]::as_ptr? Does that pointer let you use "the whole slice" when offsetting?

@Lokathor

@Lokathor yes. Those methods do the right thing. They cast the wide reference to a wide raw pointer, and only then go to thin -- so the ref-to-raw cast has the right "span" in memory.

rust-lang/rust#64980 gives a minor reason to maintain the status quo here. It includes a test-case for a dataflow analysis that computes whether a given Local is mutable through a reference. This test would show the analysis to be unsound if it were legal to offset a reference to one field into a pointer to another, disjoint field.

It is possible to relax the analysis so that it remains sound if this behavior became defined (see rust-lang/rust#65030).

See this discussion for a related example.

Another example caught by miri. The offending code:

// self.storage: Box<[MaybeUninit<u8>]>
self.storage[self.cursor]
     .as_mut_ptr()
     .cast::<T>()
     .write_unaligned(component);

Rollup merge of rust-lang#70479 - RalfJung:win-env, r=Mark-Simulacrum

A common violation of this rule is FFI structs that end with a flexible array. For example:

#[repr(C)]
struct Foo {
    // other fields
    length: u32,
    data: [u8; 0],
}
// later in code
let foo: *mut Foo = /* obtained somehow */;
let data = slice::from_raw_parts((*foo).data.as_ptr(), (*foo).length);

This pattern is used in quite a few crates that deal with windows api, and some others that don't!

That is an interesting special case. It is actually less problematic than the other cases because there is no Rust reference pointing to that "extra" memory (unlike the example in the OP where val still "owns" that extra memory). I am not sure however how to incorporate that into Stacked Borrows...

Dependabot cleanup and fixup CI (#6)

Tree Borrows solves this issue by not doing any retagging on raw pointers, and just giving them the same permission as the reference they are created from. However doing that without two-phase borrows is tricky; here's some discussion.

let val = [1u8, 2];
let ptr = &val[0] as *const u8;
let _val = unsafe { *ptr.add(1) };

The problem is that the cast to *const u8 [...]

The problem is not restricted to casts, but also affects coercions, right? Consider the equivalent (AFAICT):

.let val = [1u8, 2];
 let ptr: *const u8 = &val[0];
 let _val = unsafe { *ptr.add(1) };

A lot of the discussion regarding this has been about "casts" but even if one avoids casts, one could still be affected by this.

Yes, it applies to "ref-to-ptr coërcions" as well. I think the "cast" terminology is used here kind of indiscriminately to cover both explicit as ... casts, and implicit casts, such as the ones stemming from "coërcions" like with let ptr: *const u8 = &val[0]; or identity::<*const u8>(&val[0]). The terminology in the book about casts vs. coërcions is a bit muddy, to be honest.

Yes indeed, we often view coercions as just automatically inserted casts. Opsem discussions generally are happening on a level where all these implicit operations are made explicit. I can see how that can make the terminology confusing though.

@saethlin

I'm developing a library and ran into this.

The rules were very confusing at first, and I kept running into SB violations, but I think I understand better now. Let me describe what I did for others who are interested -- and if I'm wrong, one of the seniors can correct me.

Originally I was taking a reference to the array element and coercing it to a pointer, but that violates SB. Fortunately, I was able to adapt @saethlin 's example code and look at the linked issues, and derive a solution that made MIRI happy. The trick is to take the pointer from the big allocation, then use pointer arithmetic to arrive at the field's pointer. This way, the computed field pointer inherits the access from the big struct's pointer (which grants access to the whole allocation).

Importantly, my initial attempts to make this work kept failing. I had an Arc pointing to an allocated slice DST, and I wanted to take pointers to array elements and "rewind" them to the start of the allocation later. However, my code kept taking references that I wasn't aware of. The final solution (to get a correctly permissive pointer) looked like this:

// SharedStorage is a slice DST, with [SlotState] as the tail
// Passing the Arc and using Arc::as_ptr was the last hurdle I solved
fn get_slot_state_ptr(shared_storage: &Arc<SharedStorage>, slot_idx: usize) -> *const SlotState {
    unsafe {
        // SAFETY
        // We move the pointer to where the slot is located
        let storage_ptr = Arc::as_ptr(shared_storage);
        let ptr = storage_ptr.byte_add(SharedStorage::HEADER_BYTE_OFFSET);
        let ptr = ptr as *const SlotState;
        let ptr = ptr.add(slot_idx);
        ptr
    }
}

bitref: bit-level reference types

Navigation Menu

Repository navigation

Stacked Borrows: raw pointer usable only for `T` too strict? #134

26 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Stacked Borrows: raw pointer usable only for T too strict? #134

Description

Activity

RalfJung commented on May 28, 2019

RalfJung commented on Aug 16, 2019

RalfJung commented on Aug 17, 2019

Lokathor commented on Aug 19, 2019

RalfJung commented on Aug 20, 2019

ecstatic-morse commented on Oct 5, 2019

RalfJung commented on Dec 22, 2019

comex commented on Dec 23, 2019

retep998 commented on May 12, 2020

RalfJung commented on May 13, 2020

26 remaining items

RalfJung commented on Apr 1, 2024

briansmith commented on May 23, 2024

danielhenrymantilla commented on May 24, 2024

RalfJung commented on May 24, 2024

A248 commented on Jan 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Stacked Borrows: raw pointer usable only for `T` too strict? #134