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)
Location
https://doc.rust-lang.org/std/mem/union.MaybeUninit.html#method.zeroed
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::zeroedandstd::mem::MaybeUninitare parametrized byT. Hence, neither really exposes a concept of "raw" bytes to the user, but just the Rust type. Yet if I compare the above documentation tostd::mem::zeroedit states, among other things:So there padding bytes are explicitly excluded.
It's particularly confusing, because
std::mem::zeroedstates:Should we make it more explicit that
std::mem::MaybeUninit::zeroedalso zeroes out padding bytes? (assuming that's the behavior we want; it seems to be the behavior we currently have)