From: Alexis Bourget <alexis.bourget@gmail.com>
Date: Tue, 16 Jun 2020 21:33:23 +0000 (+0200)
Subject: Mention functions pointers in the documentation
X-Git-Url: https://git.lizzy.rs/?a=commitdiff_plain;h=15cd51af5e193789e82024ffbe194f4c0dbdfbc3;p=rust.git

Mention functions pointers in the documentation
---

diff --git a/src/libcore/mem/mod.rs b/src/libcore/mem/mod.rs
index 8bce980cadd..226454561f6 100644
--- 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")]