@@ -581,11 +581,12 @@ pub const fn needs_drop<T>() -> bool {
581
581
/// This means that, for example, the padding byte in `(u8, u16)` is not
582
582
/// necessarily zeroed.
583
583
///
584
- /// There is no guarantee that an all-zero byte-pattern represents a valid value of
585
- /// some type `T`. For example, the all-zero byte-pattern is not a valid value
586
- /// for reference types (`&T` and `&mut T`). Using `zeroed` on such types
587
- /// causes immediate [undefined behavior][ub] because [the Rust compiler assumes][inv]
588
- /// that there always is a valid value in a variable it considers initialized.
584
+ /// There is no guarantee that an all-zero byte-pattern represents a valid value
585
+ /// of some type `T`. For example, the all-zero byte-pattern is not a valid value
586
+ /// for reference types (`&T`, `&mut T` and functions pointers). Using `zeroed` on
587
+ /// such types on such types causes immediate [undefined behavior][ub] because
588
+ /// [the Rust compiler assumes][inv] that there always is a valid value in a
589
+ /// variable it considers initialized.
589
590
///
590
591
/// This has the same effect as [`MaybeUninit::zeroed().assume_init()`][zeroed].
591
592
/// It is useful for FFI sometimes, but should generally be avoided.
@@ -612,6 +613,7 @@ pub const fn needs_drop<T>() -> bool {
612
613
/// use std::mem;
613
614
///
614
615
/// let _x: &i32 = unsafe { mem::zeroed() }; // Undefined behavior!
616
+ /// let _y: fn() = unsafe { mem::zeroed() }; // And again !
615
617
/// ```
616
618
#[ inline( always) ]
617
619
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
0 commit comments