squiid/rust
1
0
Fork 0
Code Issues Pull requests Projects Activity

Rollup merge of #63215 - gnzlbg:patch-6, r=Centril

Browse source 
Clarify semantics of mem::zeroed

Clarifies the semantics of `mem::zeroed`.

r? @Centril

cc @RalfJung
This commit is contained in:
Mazdak Farrokhzad 2019-08-03 00:09:14 +02:00 committed by GitHub
commit 4520a39b94
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
src/libcore/mem/mod.rs
View file

@ -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-zero byte-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