Clarify semantics of mem::zeroed

1 files changed, 6 insertions, 3 deletions

diff --git a/src/libcore/mem/mod.rs b/src/libcore/mem/mod.rs
index bb81d7b794b..56aa145c56c 100644
--- a/src/libcore/mem/mod.rs
+++ b/src/libcore/mem/mod.rs
@@ -414,10 +414,10 @@ pub const fn needs_drop<T>() -> bool {
     intrinsics::needs_drop::<T>()
 }
 
-/// Creates a value whose bytes are all zero.
+/// Returns the value of type `T` represented by the all-zeros bit-pattern.
 ///
-/// This has the same effect as [`MaybeUninit::zeroed().assume_init()`][zeroed].
-/// It is useful for FFI sometimes, but should generally be avoided.
+/// This means that, for example, the padding byte in `(u8, u16)` is not
+/// necessarily zeroed. 
 ///
 /// There is no guarantee that an all-zero byte-pattern represents a valid value of
 /// some type `T`. For example, the all-zero byte-pattern is not a valid value
@@ -425,6 +425,9 @@ pub const fn needs_drop<T>() -> bool {
 /// causes immediate [undefined behavior][ub] because [the Rust compiler assumes][inv]
 /// that there always is a valid value in a variable it considers initialized.
 ///
+/// This has the same effect as [`MaybeUninit::zeroed().assume_init()`][zeroed].
+/// It is useful for FFI sometimes, but should generally be avoided.
+///
 /// [zeroed]: union.MaybeUninit.html#method.zeroed
 /// [ub]: ../../reference/behavior-considered-undefined.html
 /// [inv]: union.MaybeUninit.html#initialization-invariant