-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
add safety sections for three functions in core::mem #154665
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -666,16 +666,18 @@ pub const fn needs_drop<T: ?Sized>() -> 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`, `&mut T`) and function pointers. 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. | ||
| /// | ||
| /// This has the same effect as [`MaybeUninit::zeroed().assume_init()`][zeroed]. | ||
| /// It is useful for FFI sometimes, but should generally be avoided. | ||
| /// | ||
| /// | ||
| /// # Safety | ||
| /// | ||
| /// The all-zero byte-pattern must represent a valid value of some type `T`. | ||
| /// For example, it is not valid for reference types (`&T`, `&mut T`) or function | ||
| /// pointers. 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. | ||
| /// | ||
| /// [zeroed]: MaybeUninit::zeroed | ||
| /// [ub]: ../../reference/behavior-considered-undefined.html | ||
| /// [inv]: MaybeUninit#initialization-invariant | ||
|
|
@@ -731,7 +733,10 @@ pub const unsafe fn zeroed<T>() -> T { | |
| /// This makes it undefined behavior to have uninitialized data in a variable even | ||
| /// if that variable has an integer type. | ||
| /// | ||
| /// Therefore, it is immediate undefined behavior to call this function on nearly all types, | ||
| /// | ||
| /// # Safety | ||
| /// | ||
| /// It is immediate undefined behavior to call this function on nearly all types, | ||
| /// including integer types and arrays of integer types, and even if the result is unused. | ||
|
Comment on lines
+739
to
740
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not a safety section, this is an editorial. A safety section should be describing the rules for when it is defined behaviour to call.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think there's any way to use this without language UB.
in the safety section? |
||
| /// | ||
| /// [uninit]: MaybeUninit::uninit | ||
|
|
@@ -1024,20 +1029,15 @@ pub const fn copy<T: Copy>(x: &T) -> T { | |
| *x | ||
| } | ||
|
|
||
| /// Interprets `src` as having type `&Dst`, and then reads `src` without moving | ||
| /// the contained value. | ||
| /// Interprets `src` as having type `&Dst`, and then reads `src` without moving the contained value. | ||
| /// The function will panic if [`size_of::<Src>`][size_of] is less than [`size_of::<Dst>`][size_of]. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Guaranteeing a panic here probably ought to at least get signed off on by libs-api. |
||
| /// | ||
| /// This function will unsafely assume the pointer `src` is valid for [`size_of::<Dst>`][size_of] | ||
| /// bytes by transmuting `&Src` to `&Dst` and then reading the `&Dst` (except that this is done | ||
| /// in a way that is correct even when `&Dst` has stricter alignment requirements than `&Src`). | ||
| /// It will also unsafely create a copy of the contained value instead of moving out of `src`. | ||
| /// # Safety | ||
| /// | ||
| /// It is not a compile-time error if `Src` and `Dst` have different sizes, but it | ||
| /// is highly encouraged to only invoke this function where `Src` and `Dst` have the | ||
| /// same size. This function triggers [undefined behavior][ub] if `Dst` is larger than | ||
| /// `Src`. | ||
| /// * The first [`size_of::<Dst>`][size_of] bytes of memory pointed to by `src` must represent | ||
| /// a valid value of type `Dst`. | ||
| /// * Users must ensure that creating the returned value does not violate Rust's aliasing rules. | ||
| /// | ||
|
hxuhack marked this conversation as resolved.
|
||
| /// [ub]: ../../reference/behavior-considered-undefined.html | ||
| /// | ||
| /// # Examples | ||
| /// | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
View changes since the review