From 579099ab5788ef839d784365c1d3724b8391c074 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 7 Jun 2018 23:53:30 +0200 Subject: [PATCH 1/2] Improve docs for slice::from_raw_parts --- src/libcore/slice/mod.rs | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/libcore/slice/mod.rs b/src/libcore/slice/mod.rs index 63f9a8097ba3a..bfab7a4cddac5 100644 --- a/src/libcore/slice/mod.rs +++ b/src/libcore/slice/mod.rs @@ -3873,9 +3873,11 @@ unsafe impl<'a, T> TrustedRandomAccess for ExactChunksMut<'a, T> { /// valid for `len` elements, nor whether the lifetime inferred is a suitable /// lifetime for the returned slice. /// -/// `p` must be non-null and aligned, even for zero-length slices, as is -/// required for all references. However, for zero-length slices, `p` can be -/// a bogus non-dereferencable pointer such as [`NonNull::dangling()`]. +/// `data` must be non-null and aligned, even for zero-length slices. The +/// 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` +/// for zero-length slices using [`NonNull::dangling()`]. /// /// # Caveat /// @@ -3910,8 +3912,8 @@ pub unsafe fn from_raw_parts<'a, T>(data: *const T, len: usize) -> &'a [T] { /// /// This function is unsafe for the same reasons as `from_raw_parts`, as well /// as not being able to provide a non-aliasing guarantee of the returned -/// mutable slice. `p` must be non-null and aligned even for zero-length slices as with -/// `from_raw_parts`. +/// mutable slice. `data` must be non-null and aligned even for zero-length +/// slices as with `from_raw_parts`. #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T] { From 426f06f8fea9783a63aa61b418ab0ecb723a5ad9 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sat, 9 Jun 2018 10:40:51 +0200 Subject: [PATCH 2/2] Be more precise about why references need to be non-null and aligned --- src/libcore/slice/mod.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libcore/slice/mod.rs b/src/libcore/slice/mod.rs index bfab7a4cddac5..6f4c130d8f318 100644 --- a/src/libcore/slice/mod.rs +++ b/src/libcore/slice/mod.rs @@ -3873,7 +3873,7 @@ unsafe impl<'a, T> TrustedRandomAccess for ExactChunksMut<'a, T> { /// valid for `len` elements, nor whether the lifetime inferred is a suitable /// lifetime for the returned slice. /// -/// `data` must be non-null and aligned, even for zero-length slices. The +/// `data` must be non-null and aligned, even for zero-length slices. 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`