Document valid pointer and Box transmutations#2282
Open
traviscross wants to merge 7 commits into
Open
Conversation
The pointer-to-pointer cast rules and the wide-pointer validity rule both speak of the *metadata* of a pointer, but we hadn't explicitly defined the term (even though we had defined the contents of that metadata). Let's do that and link to it.
We refer to the unsized tail of a type, but we hadn't defined it. Let's do that and link to the definition.
traviscross
force-pushed
the
TC/box-transmute-validity
branch
from
e75977e to
b624dd7
Compare
| * Pointers to trait objects also store a pointer to a vtable. | ||
| * [Pointer types] to <abbr title="dynamically sized types">DSTs</abbr> are sized but have twice the size of pointers to sized types, since they also store *metadata*: | ||
| * Pointers to slices store the number of elements; pointers to `str` store the length in bytes. | ||
| * Pointers to trait objects store a pointer to a vtable. |
Member
There was a problem hiding this comment.
Comparing notes with https://doc.rust-lang.org/nightly/std/ptr/trait.Pointee.html#pointer-metadata, I think the only missing piece is the "unsized / last field" indirection for indirectly unsized types.
traviscross
force-pushed
the
TC/box-transmute-validity
branch
from
b624dd7 to
5a667b1
Compare
ehuss
reviewed
Jun 9, 2026
| <!-- Editor Note: This is nowhere close to an exhaustive list --> | ||
|
|
||
| r[lang-types.box.transmute] | ||
| For types `T` and `U` such that `*mut T` and `*mut U` have the same layout (per [layout.pointer.parametric]) and a [pointer-to-pointer cast] from `*mut T` to `*mut U` is permitted, transmuting a `Box<T>` to a `Box<U>`, where both boxes use the global allocator, is sound when both of the following hold: |
Contributor
There was a problem hiding this comment.
Just curious, why "global" here?
Member
There was a problem hiding this comment.
Box with a custom allocator is not necessarily going to put the allocator in the same place -- e.g. under -Zrandomize-layout -- for different value types, so I don't think we can make this guarantee. Maybe it can be made for 1-ZST allocators? Not sure...
Member
There was a problem hiding this comment.
Big fan of sticking to just Global here for now. We can talk about the more complex cases later.
(See the similar discussion about how we might be fine in rust-lang/rfcs#3775 to define the field order of *const [T] but are not ready to define the field order of Vec<T>.)
We guarantee various things about the layout of pointers and references, but we'd made no guarantees of equivalence between two pointers to distinct unsized types that differ in the unsized tail. Let's make some useful guarantees about this.
Our rules for `as` casts document which pointer-to-pointer casts are valid. For unsized types, this validity is based on the compatibility of the pointer metadata. Using this and our layout equivalences, we can define when a pointer transmute will produce the same pointer value as would a cast. Let's define that.
We hadn't documented when it's sound to transmute a `Box<T>` to a `Box<U>`. Now that we've documented when `*mut T` and `*mut U` can be assumed to have the same layout, let's use that to document when this transmute is sound.
The validity rule for the metadata of a wide reference, `Box<T>`, or raw pointer mentions `dyn Trait` and slice but had omitted `str`. Let's fix that.
traviscross
force-pushed
the
TC/box-transmute-validity
branch
from
5a667b1 to
6ca17b8
Compare
rustbot
added
the
S-waiting-on-review
Contributor
Author
|
cc @RalfJung |
traviscross
added
I-lang-nominated
| The raw pointer types `*const T` and `*const U` have the same layout, as do `*mut T` and `*mut U`, the shared references `&T` and `&U`, and the mutable references `&mut T` and `&mut U`, in each of the following cases: | ||
|
|
||
| - `T` and `U` are both sized types. | ||
| - `T` and `U` both have a [slice] or [`str`] as their [unsized tail]. |
Contributor
There was a problem hiding this comment.
I find this wording confusing (e.g., are you intending to guarantee that &[u8] and &str have the same layout)?
Contributor
There was a problem hiding this comment.
I guess you are, based on the test below.
Contributor
Author
There was a problem hiding this comment.
We already guarantee that:
A reference
&strhas the same layout as a reference&[u8].
This PR further guarantees that pointers with any slice-type metadata have the same layout as pointers with str metadata.
We document that, for references and `Box<T>`, pointed-to values with slice or `str` metadata must be no larger than `isize::MAX`. We hadn't required this for pointed-to values with `dyn` metadata. It's tempting to think this isn't necessary since we separately require that the metadata point to a vtable generated by the compiler, which ensures the encoded size of the erased type is OK. But the bound is on the total size of the pointed-to value, including any sized prefix of a type with an unsized tail. Since the prefix combined with the size in the vtable can push us past the limit, we need the separate restriction. Let's apply the rule to both cases and add an admonition to remind ourselves of why this is needed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is best reviewed commit by commit.
Related to:
Boxrust#155597