Unexpected undefined behavior when assigning a function pointer to std::mem::zeroed()

[archshift]

Note: the following behavior only exists when compiling with optimizations (a.k.a. release mode).

Example 1:

pub fn bar() -> usize {
    let foo: fn() = unsafe { ::std::mem::zeroed() };
    foo as usize
}

This emits (as of 1.26.0):

  push rbp
  mov rbp, rsp
  ud2

Whereas it used to have expected behavior up until 1.19.0:

  push rbp
  mov rbp, rsp
  xor eax, eax
  pop rbp
  ret

Example 2:

A bit of an odd case I discovered, which results in what seems to be some stack corruption:

pub struct Foo<T: Copy> {
    map_keys: [u64; 64],
    map_vals: T,
}

impl<T: Copy> Foo<T> {
    pub fn new() -> Self {
        Foo {
            map_keys: [!0; 64],
            map_vals: unsafe { ::std::mem::zeroed() }
        }
    }
}

fn main() {
    Foo::<fn()>::new();
}

Playground link

---

What I think is striking here is that this behavior occurs while never even dereferencing the pointer!. This allows one to shoot oneself in the foot when trying to, for example, set a default value for a function pointer member.

[petrochenkov]

"Function pointers" are actually "function references", so they can't be null (and optimizer can rely on that), so Option<fn()> needs to be used for nullable function pointers (as explained in the documentation).

[hanna-kruppe]

Yeah, this might surprise people, but it's working as intended: creating a bit pattern that is invalid for a type and unsafely claiming it to be of that type is instant UB, and has to be to enable a variety of optimizations. One more reason to be extremely careful with mem::zeroed (e.g., the Foo type in example 2 is unsound for many Copy types T, not just fn types).

We might want to explicitly call this out in more places (e.g., in the reference and in the nomicon) since quite a few people trip over this, but it's not going to change.

[steveklabnik]

Let's put this stuff in mem::zeroed's docs.