Doc clarification for MaybeUninit::zeroed()

[danielocfb]

Location

https://doc.rust-lang.org/std/mem/union.MaybeUninit.html#method.zeroed

Creates a new MaybeUninit in an uninitialized state, with the memory being filled with 0 bytes. It depends on T whether that already makes for proper initialization. For example, MaybeUninit::zeroed() is initialized, but MaybeUninit<&'static i32>::zeroed() is not because references must not be null.

Summary

While perhaps implied by the terminology of "memory being filled with 0 bytes", it would be great to explicitly state whether or not padding bytes are included.

For me it's a bit ambiguous because both std::mem::zeroed and std::mem::MaybeUninit are parametrized by T. Hence, neither really exposes a concept of "raw" bytes to the user, but just the Rust type. Yet if I compare the above documentation to std::mem::zeroed it states, among other things:

This means that, for example, the padding byte in (u8, u16) is not necessarily zeroed.

So there padding bytes are explicitly excluded.

It's particularly confusing, because std::mem::zeroed states:

This has the same effect as MaybeUninit::zeroed().assume_init(). It is useful for FFI sometimes, but should generally be avoided.

Should we make it more explicit that std::mem::MaybeUninit::zeroed also zeroes out padding bytes? (assuming that's the behavior we want; it seems to be the behavior we currently have)

[quaternic]

Should we make it more explicit that std::mem::MaybeUninit::zeroed also zeroes out padding bytes? (assuming that's the behavior we want; it seems to be the behavior we currently have)

The difference between

let zeroed = MaybeUninit::<(u8, u16)>::zeroed();
ptr::copy::<MaybeUninit<(u8, u16)>>(&zeroed as *const _ as *const _, x, 1);
// does not necessarily overwrite the padding byte

and

let zeroed = [0u16; 2];
ptr::copy::<MaybeUninit<(u8, u16)>>(&zeroed as *const _ as *const _, x, 1);
// writes all four bytes

seems to imply that MaybeUninit::<(u8, u16)>::zeroed() leaves the padding byte undefined. playground

[danielocfb]

Yeah, I think #111616 is looking into that behavior. Sorry if I have misrepresented it, I just peeked at the code and the above was my conclusion.