Is it sound to produce &[u8] and &UnsafeCell to the same memory so long as the latter isn't "used"?
#455
Comments
|
This is intended to be sound but Stacked Borrows has issues with it, see #303. |
|
Gotcha. Sounds like the current state of things is that:
Is it the case that, as is mentioned in the issue you linked, replacing |
|
The issue mentions replacing |
To add to the list: under Tree Borrows, this is sound. |
Ah gotcha. I'm asking a slightly different question, which is: Does stacked borrows consider it insta-UB to have Unfortunately, I answered my own question in the negative (that code is adapted from the code in #303). |
|
Yeah there is no way to mask / disable interior mutability.
|
Previously, we required there to always be "`UnsafeCell` agreement" between any `Ptr`s or references referencing a given region of memory. This was based on an overly-strict interpretation of the semantics of `UnsafeCell`. In this commit, we relax `Ptr` to only require "`UnsafeCell` agreement" when the aliasing model is `Shared`. All of the places that our internal invariants are "consumed" - ie, where we use them as safety preconditions for calling unsafe functions defined outside our crate - this relaxation is sufficient. This is based on what we (@jswrenn and I) believe to be a more accurate model of the semantics of `UnsafeCell`s. In particular, `UnsafeCell`s do not affect the semantics of loads or stores in Rust. All they do is affect the semantics of shared references. In particular, Rust assumes that the referent of a shared reference will not be stored to during the lifetime of any shared reference, but this assumption is not made for bytes which are covered by an `UnsafeCell`. This is entirely a runtime property. If two references refer to the same memory, but disagree on whether that memory is covered by an `UnsafeCell`, this results in UB if the `UnsafeCell` is used to store to the memory, violating the expectations of the non-`UnsafeCell` shared reference. This commit is consistent with the runtime nature of this property, but is inconsistent with Stacked Borrows (rust-lang/unsafe-code-guidelines#455). However, this is considered to be a bug in Stacked Borrows.
Previously, we required there to always be "`UnsafeCell` agreement" between any `Ptr`s or references referencing a given region of memory. This was based on an overly-strict interpretation of the semantics of `UnsafeCell`. In this commit, we relax `Ptr` to only require "`UnsafeCell` agreement" when the aliasing model is `Shared`. All of the places that our internal invariants are "consumed" - ie, where we use them as safety preconditions for calling unsafe functions defined outside our crate - this relaxation is sufficient. This is based on what we (@jswrenn and I) believe to be a more accurate model of the semantics of `UnsafeCell`s. In particular, `UnsafeCell`s do not affect the semantics of loads or stores in Rust. All they do is affect the semantics of shared references. In particular, Rust assumes that the referent of a shared reference will not be stored to during the lifetime of any shared reference, but this assumption is not made for bytes which are covered by an `UnsafeCell`. This is entirely a runtime property. If two references refer to the same memory, but disagree on whether that memory is covered by an `UnsafeCell`, this results in UB if the `UnsafeCell` is used to store to the memory, violating the expectations of the non-`UnsafeCell` shared reference. This commit is consistent with the runtime nature of this property, but is inconsistent with Stacked Borrows (rust-lang/unsafe-code-guidelines#455). However, this is considered to be a bug in Stacked Borrows.
Is it sound to produce a
&[u8]and a&UnsafeCellwhich 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
MaybeValidtype).The text was updated successfully, but these errors were encountered: