Ptr type needs to handle zero-sized types
#874
Labels
blocking-next-release
This issue should be resolved before we release on crates.io
Comments
This was referenced Feb 13, 2024
joshlf
added
the
blocking-next-release
joshlf
added a commit
that referenced
this issue
Sep 7, 2024
Now that [1] is completed, zero-sized accesses no longer require provenance. Per [2], zero-sized references are no longer required to be dereferenceable, and so may not carry provenance. This commit updates `Ptr`'s invariants to not require provenance or a valid allocation when its referent is zero-sized. [1] rust-lang/rust#117945 [2] rust-lang/rust#125021 Closes #874
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 7, 2024
Now that [1] is completed, zero-sized accesses no longer require provenance. Per [2], zero-sized references are no longer required to be dereferenceable, and so may not carry provenance. This commit updates `Ptr`'s invariants to not require provenance or a valid allocation when its referent is zero-sized. [1] rust-lang/rust#117945 [2] rust-lang/rust#125021 Closes #874
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Progress
Details
Credit to @djkoloski for noticing this issue.
Currently, the
Ptrtype's internal invariants require that the pointer point to a valid allocation. However, theptrmodule docs imply that zero-sized accesses do not require a pointer to a valid allocation. This is problematic for us, since it implies that Rust could generate a reference to a ZST which does not point to an allocation. Thus, our impl ofFrom<&T> for Ptr<T>might be unsound (albeit in a way that isn't currently exercisable): it promises that, based on the fact that&Tis a reference, it must refer to a valid allocation. IfTis a ZST, that implication might not hold.We should do the following:
The text was updated successfully, but these errors were encountered: