Skip to content

explicitly keep the door open for some but not all subobject provenance #2338

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
RalfJung wants to merge 1 commit into
base: master
Choose a base branch
from
+12 −0
Open

explicitly keep the door open for some but not all subobject provenance #2338

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions src/behavior-considered-undefined.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,18 @@ r[undefined.alias]

All this also applies when values of these types are passed in a (nested) field of a compound type, but not behind pointer indirections.

r[undefined.subobject]
* Using a pointer or reference outside the subrange of memory it is allowed to access.

Generally, a reference may only access the memory it [points to].
This restriction also applies to all raw pointers derived from this reference.
The one exception is that a reference to an element of an array or slice may be used to access other elements of the same array or slice without immediately causing undefined behavior.

@joshlf joshlf Sep 2, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this play with transmutes? Consider:

#[repr(C)]
struct Pair {
    first: [usize; 4],
    second: [usize; 4],
}

let pair = &Pair { ... };
let arr: &[usize; 8] = unsafe { &*(pair as *const Pair) };
let i0: *const usize = &arr[0];
let i7 = unsafe { i0.add(7) };
let i7 = unsafe { &*i7 };

This goes from:

  • &Pair to &[usize; 8] (a sound transmute)
  • ...to a raw pointer to the 0th element
  • ...to a raw pointer to the 7th element
  • ...to a reference to the 7th element

Presumably if we skipped the &Pair -> &[usize; 8] step and instead constructed i0 from &pair.first[0], this would be unsound because it would entail jumping between first and second.

Two questions:

  • Am I correct that the code as written is sound, and that if we skipped &Pair -> &[usize; 8], it would not be sound?
  • If so, what accounts for the differing soundness between these two examples?

View changes since the review

This exception also applies for nested arrays, but not for fields of values inside arrays.

@joshlf joshlf Sep 2, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we clarify what "this exception also applies for nested arrays" means? I presume it means that you can go from e.g. x[0][0] to x[1][1] (where x: [[usize; 2]; 2])? What about from x[0] to x[1][1] or from x[0][0] to x[1]?

View changes since the review


Furthermore, a reference to a field of an enum may not be used to change the discriminant of said enum.
If the tag lies inside the range of memory accessible by the reference (as in the previous paragraph), then the reference may be used to *temporarily* change the discriminant of the enum without immediately causing undefined behavior, but the original discriminant must be restored before the lifetime of the reference ends.

@joshlf joshlf Sep 2, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "as in the previous paragraph" refer to?

View changes since the review

@joshlf joshlf Sep 2, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if changing the discriminant has the effect of just doing a transmute? E.g.:

#[repr(u8)]
enum Zero { Zero = 0 }

#[repr(u8)]
enum One { One = 1 }

enum Bit {
    Zero(Zero),
    One(One),
}

If Rust chooses to niche-optimize Bit so that there's no explicit discriminant, then given *mut Zero pointing to the only field of Bit::Zero, you could overwrite it with One::One and you'd effectively have transmuted the entire Bit to Bit::One(One::One). Is this sound even if the discriminant is not restored?

View changes since the review

@joshlf joshlf Sep 2, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We often say that lifetimes are not relevant to opsem. What does the term "lifetime" mean in this context? Is this about crossing an API boundary (i.e., this is really a safety thing about what you're allowed to assume when an enum reference/pointer crosses an API boundary), or is this about SB/TB, or something else?

View changes since the review

This restriction also applies to all raw pointers derived from this reference.

r[undefined.immutable]
* Mutating immutable bytes. All bytes reachable through a [const-promoted] expression are immutable, as well as bytes reachable through borrows in `static` and `const` initializers that have been [lifetime-extended] to `'static`. The bytes owned by an immutable binding or immutable `static` are immutable, unless those bytes are part of an [`UnsafeCell<U>`].

Expand Down
Loading