Partial pointers in padding can make const-eval fail

[theemathas]

I'm not sure if this is a bug or not.

#![allow(unused)]

#[repr(C, align(16))]
#[derive(Clone, Copy)]
struct Thing {
    x: u128,
    y: u64,
    // Replace the above line with the below line to make it stop compiling
    // y: std::mem::MaybeUninit<u64>,
    // 8 bytes of padding here
}
#[derive(Clone, Copy)]
union PreservePad {
    thing: Thing,
    bytes: [u8; 32],
}

const A: Thing = unsafe {
    let mut buffer = [PreservePad { bytes: [0u8; 32] }; 2];
    (&raw mut buffer).cast::<&i32>().byte_add(28).write_unaligned(&1);
    buffer[0].thing
};

fn main() {}

The above code compiles fine, even in Miri. However, changing the y: u64line to y: std::mem::MaybeUninit<u64> causes the following compile error:

error[E0080]: unable to read parts of a pointer from memory at alloc4
  --> src/main.rs:21:5
   |
21 |     buffer[0].thing
   |     ^^^^^^^^^^^^^^^ evaluation of `A` failed here
   |
   = help: this code performed an operation that depends on the underlying bytes representing a pointer
   = help: the absolute address of a pointer is not known at compile-time, so such operations are not supported

For more information about this error, try `rustc --explain E0080`.

It seems that copying Thing in consteval discards the padding if y is a u64, but copies the padding if y is a MaybeUninit<u64>. This is implemented in the compiler here and here.

Normally, this implementation detail is observable in user code only by, say, printing padding bytes after doing a copy, which is UB. However, the compiler also cares about the contents of padding bytes potentially containing pointer fragments, making the implementation detail observable in user code without invoking UB.

cc @RalfJung

Somewhat related to #147959 and #148259, but this issue doesn't depend on those two issues.

Meta

Reproducible on the playground with stable rust version 1.91.0

[RalfJung]

That seems entirely expected to me? There are much simpler ways to observe the same thing, e.g.

const WORKS: MaybeUninit<usize> = unsafe { transmute(&1) };
const FAILS: usize = unsafe { transmute(&1) };

Transmuting a pointer to an integer is UB. We even document this, though that is probably hard to find. Your example that causes the error does a ptr-to-int transmute; the variant that does not error has no such transmute.

I don't see in which sense this depends on any "compiler internals".

[RalfJung]

Oh wait, I misread, it's the other way around in your example -- the version with MaybeUninit fails, and with an integer it works? Very strange.

[RalfJung]

Ah, so the problem is that when Thing is (u128, u64), copying a Thing copies its two fields but doesn't even look at the padding. When we make one field MaybeUninit, we instead copy the entire Thing as raw bytes, including the padding, which leads us to read the first half of that pointer that you wrote at the boundary of the two array elements in buffer.

With #148259, the error message for the failing example changes:

error: encountered partial pointer in final value of constant
  --> theemathas.rs:18:1
   |
18 | const A: Thing = unsafe {
   | ^^^^^^^^^^^^^^
   |
   = note: while pointers can be broken apart into individual bytes during const-evaluation, only complete pointers (with all their bytes in the right order) are supported in the final value

error: aborting due to 1 previous error

That's good, it means the error happens later.

If we make it so that we reset the padding of a const-eval result to uninit before checking for partial pointers, we should be able to accept both versions of this.

Cc @rust-lang/wg-const-eval

[theemathas]

I found this code which compiles normally, but fails to compile (not UB) with Miri:

#![allow(unused)]

use std::mem::MaybeUninit;

#[repr(C, align(16))]
#[derive(Clone, Copy)]
struct Thing {
    x: u128,
    y: MaybeUninit<u64>,
    // 8 bytes of padding here
}

const A: Thing = unsafe {
    let mut buffer = Thing { x: 0, y: MaybeUninit::new(0) };
    (&raw mut buffer).cast::<&i32>().byte_add(20).write_unaligned(&1);
    buffer
};

fn main() {}

Miri output:

error[E0080]: unable to read parts of a pointer from memory at alloc10
  --> src/main.rs:13:1
   |
13 | const A: Thing = unsafe {
   | ^^^^^^^^^^^^^^ evaluation of `A` failed here
   |
   = help: this code performed an operation that depends on the underlying bytes representing a pointer
   = help: the absolute address of a pointer is not known at compile-time, so such operations are not supported

error: aborting due to 1 previous error

Note that the pointer straddles between a MaybeUninit and padding bytes.

This code would also fail to compile after your proposed change (resetting padding bytes to uninit in the final value of consteval). I'm guessing that Miri already does something along those lines.

[oli-obk]

Miri uses -Zextra-const-ub-checks. If you compile with rustc and that flag you get the same ctfe error. It's just a considerable slowdown on normal ctfe, so it's not turned on by default