Mention functions pointers in the documentation

diff --git a/src/libcore/mem/mod.rs b/src/libcore/mem/mod.rs
index 8bce980cadd1e46221d7c915625248a54cb68d7f..226454561f6fe42df2e7faaa7b71f8c0a68cd11b 100644 (file)
--- a/src/libcore/mem/mod.rs
+++ b/src/libcore/mem/mod.rs
@@ -581,11 +581,12 @@ pub const fn needs_drop<T>() -> bool {
 /// 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
-/// for reference types (`&T` and `&mut T`). Using `zeroed` on such types
-/// causes immediate [undefined behavior][ub] because [the Rust compiler assumes][inv]
-/// that there always is a valid value in a variable it considers initialized.
+/// 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
+/// for reference types (`&T`, `&mut T` and functions pointers). Using `zeroed` on
+/// such types on such types 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.
@@ -612,6 +613,7 @@ pub const fn needs_drop<T>() -> bool {
 /// use std::mem;
 ///
 /// let _x: &i32 = unsafe { mem::zeroed() }; // Undefined behavior!
+/// let _y: fn() = unsafe { mem::zeroed() }; // And again !
 /// ```
 #[inline(always)]
 #[stable(feature = "rust1", since = "1.0.0")]