mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

clarify language around non-null ptrs in slice::raw

Browse Source
This commit is contained in:
oskgo 2024-09-02 15:49:18 +02:00
parent 9b82580c73
commit 7494224e74
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
library/core/src/slice/raw.rs
View File

@ -11,13 +11,13 @@
///
/// Behavior is undefined if any of the following conditions are violated:
///
/// * `data` must be [valid] for reads for `len * mem::size_of::<T>()` many bytes,
/// * `data` must be non-null, [valid] for reads for `len * mem::size_of::<T>()` many bytes,
/// and it must be properly aligned. This means in particular:
///
/// * The entire memory range of this slice must be contained within a single allocated object!
/// Slices can never span across multiple allocated objects. See [below](#incorrect-usage)
/// for an example incorrectly not taking this into account.
/// * `data` must be non-null and aligned even for zero-length slices. One
/// * `data` must be non-null and aligned even for zero-length slices or slices of ZSTs. One
/// reason for this is that enum layout optimizations may rely on references
/// (including slices of any length) being aligned and non-null to distinguish
/// them from other data. You can obtain a pointer that is usable as `data`
@ -146,12 +146,12 @@
///
/// Behavior is undefined if any of the following conditions are violated:
///
/// * `data` must be [valid] for both reads and writes for `len * mem::size_of::<T>()` many bytes,
/// * `data` must be non-null, [valid] for both reads and writes for `len * mem::size_of::<T>()` many bytes,
/// and it must be properly aligned. This means in particular:
///
/// * The entire memory range of this slice must be contained within a single allocated object!
/// Slices can never span across multiple allocated objects.
/// * `data` must be non-null and aligned even for zero-length slices. One
/// * `data` must be non-null and aligned even for zero-length slices or slices of ZSTs. One
/// reason for this is that enum layout optimizations may rely on references
/// (including slices of any length) being aligned and non-null to distinguish
/// them from other data. You can obtain a pointer that is usable as `data`
@ -219,7 +219,7 @@ pub const fn from_mut<T>(s: &mut T) -> &mut [T] {
///
/// Behavior is undefined if any of the following conditions are violated:
///
/// * The `start` pointer of the range must be a [valid] and properly aligned pointer
/// * The `start` pointer of the range must be a non-null, [valid] and properly aligned pointer
/// to the first element of a slice.
///
/// * The `end` pointer must be a [valid] and properly aligned pointer to *one past*
@ -235,7 +235,7 @@ pub const fn from_mut<T>(s: &mut T) -> &mut [T] {
/// of lifetime `'a`, except inside an `UnsafeCell`.
///
/// * The total length of the range must be no larger than `isize::MAX`,
/// and adding that size to `data` must not "wrap around" the address space.
/// and adding that size to `start` must not "wrap around" the address space.
/// See the safety documentation of [`pointer::offset`].
///
/// Note that a range created from [`slice::as_ptr_range`] fulfills these requirements.
@ -288,7 +288,7 @@ pub const fn from_mut<T>(s: &mut T) -> &mut [T] {
///
/// Behavior is undefined if any of the following conditions are violated:
///
/// * The `start` pointer of the range must be a [valid] and properly aligned pointer
/// * The `start` pointer of the range must be a non-null, [valid] and properly aligned pointer
/// to the first element of a slice.
///
/// * The `end` pointer must be a [valid] and properly aligned pointer to *one past*
@ -305,7 +305,7 @@ pub const fn from_mut<T>(s: &mut T) -> &mut [T] {
/// Both read and write accesses are forbidden.
///
/// * The total length of the range must be no larger than `isize::MAX`,
/// and adding that size to `data` must not "wrap around" the address space.
/// and adding that size to `start` must not "wrap around" the address space.
/// See the safety documentation of [`pointer::offset`].
///
/// Note that a range created from [`slice::as_mut_ptr_range`] fulfills these requirements.