Skip to content

Is it sound to produce &[u8] and &UnsafeCell to the same memory so long as the latter isn't "used"? #455

Open
@joshlf

Description

@joshlf

Is it sound to produce a &[u8] and a &UnsafeCell which refer to the same region of memory and are live at the same time so long as no code performs mutation operations via the latter reference?

If this is sound, then it's possible to write a wrapper type which "disables" interior mutability by simply not exposing it, which is useful for caes such as google/zerocopy#5 (specifically, we are running into issues with how to define the MaybeValid type).

Activity

RalfJung

RalfJung commented on Aug 29, 2023

@RalfJung
Member

This is intended to be sound but Stacked Borrows has issues with it, see #303.

joshlf

joshlf commented on Aug 29, 2023

@joshlf
Author

Gotcha. Sounds like the current state of things is that:

  • It's desirable that this is sound
  • It's not currently guaranteed that this is sound
  • Under stacked borrows, this is not sound

Is it the case that, as is mentioned in the issue you linked, replacing &UnsafeCell with &MaybeUninit<UnsafeCell> makes it so that this is guaranteed to be sound? Or, as is speculated in the issue thread, is that just a limitation of Miri being able to see through MaybeUninit?

RalfJung

RalfJung commented on Aug 29, 2023

@RalfJung
Member

The issue mentions replacing UnsafeCell<T> with MaybeUninit<T>. That is unsound, &MaybeUninit<T> must be read-only like all shared references. I have no idea what the person in the issue meant when they said using MaybeUninit could help; it shouldn't make a difference (and we never got an example of it making a difference, so I think they were just confused and there are other things that changed at the same time).

RalfJung

RalfJung commented on Aug 29, 2023

@RalfJung
Member

Gotcha. Sounds like the current state of things is that:

To add to the list: under Tree Borrows, this is sound.

joshlf

joshlf commented on Aug 29, 2023

@joshlf
Author

The issue mentions replacing UnsafeCell<T> with MaybeUninit<T>. That is unsound, &MaybeUninit<T> must be read-only like all shared references. I have no idea what the person in the issue meant when they said using MaybeUninit could help; it shouldn't make a difference (and we never got an example of it making a difference, so I think they were just confused and there are other things that changed at the same time).

Ah gotcha. I'm asking a slightly different question, which is: Does stacked borrows consider it insta-UB to have &[u8] and &MaybeUninit<UnsafeCell> live at the same time? In other words, does MaybeUninit (or really any similarly-shaped union) serve as the hypothetical "disable interior mutability" type I was referring to in the original comment?

Unfortunately, I answered my own question in the negative (that code is adapted from the code in #303).

RalfJung

RalfJung commented on Aug 29, 2023

@RalfJung
Member
added a commit that references this issue on May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @RalfJung@joshlf

        Issue actions

          Is it sound to produce `&[u8]` and `&UnsafeCell` to the same memory so long as the latter isn't "used"? · Issue #455 · rust-lang/unsafe-code-guidelines