Skip to content

Commit dc2237c

Browse files
committed
apply feedback
1 parent 4ed469c commit dc2237c

File tree

2 files changed

+28
-20
lines changed

2 files changed

+28
-20
lines changed

src/libcore/intrinsics.rs

Lines changed: 20 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -967,10 +967,11 @@ extern "rust-intrinsic" {
967967
///
968968
/// For regions of memory which might overlap, use [`copy`] instead.
969969
///
970-
/// `copy_nonoverlapping` is semantically equivalent to C's [`memcpy`].
970+
/// `copy_nonoverlapping` is semantically equivalent to C's [`memcpy`], but
971+
/// with the argument order swapped.
971972
///
972973
/// [`copy`]: ./fn.copy.html
973-
/// [`memcpy`]: https://www.gnu.org/software/libc/manual/html_node/Copying-Strings-and-Arrays.html#index-memcpy
974+
/// [`memcpy`]: https://en.cppreference.com/w/c/string/byte/memcpy
974975
///
975976
/// # Safety
976977
///
@@ -1020,15 +1021,15 @@ extern "rust-intrinsic" {
10201021
/// let dst_ptr = dst.as_mut_ptr().offset(dst_len as isize);
10211022
/// let src_ptr = src.as_ptr();
10221023
///
1024+
/// // Truncate `src` without dropping its contents. We do this first,
1025+
/// // to avoid problems in case something further down panics.
1026+
/// src.set_len(0);
1027+
///
10231028
/// // The two regions cannot overlap becuase mutable references do
10241029
/// // not alias, and two different vectors cannot own the same
10251030
/// // memory.
10261031
/// ptr::copy_nonoverlapping(src_ptr, dst_ptr, src_len);
10271032
///
1028-
/// // Truncate `src` without dropping its contents. This cannot panic,
1029-
/// // so double-drops cannot happen.
1030-
/// src.set_len(0);
1031-
///
10321033
/// // Notify `dst` that it now holds the contents of `src`.
10331034
/// dst.set_len(dst_len + src_len);
10341035
/// }
@@ -1053,12 +1054,12 @@ extern "rust-intrinsic" {
10531054
/// If the source and destination will *never* overlap,
10541055
/// [`copy_nonoverlapping`] can be used instead.
10551056
///
1056-
/// `copy` is semantically equivalent to C's [`memmove`]. Copying takes place as
1057-
/// if the bytes were copied from `src` to a temporary array and then copied from
1058-
/// the array to `dst`-
1057+
/// `copy` is semantically equivalent to C's [`memmove`], but with the argument
1058+
/// order swapped. Copying takes place as if the bytes were copied from `src`
1059+
/// to a temporary array and then copied from the array to `dst`.
10591060
///
10601061
/// [`copy_nonoverlapping`]: ./fn.copy_nonoverlapping.html
1061-
/// [`memmove`]: https://www.gnu.org/software/libc/manual/html_node/Copying-Strings-and-Arrays.html#index-memmove
1062+
/// [`memmove`]: https://en.cppreference.com/w/c/string/byte/memmove
10621063
///
10631064
/// # Safety
10641065
///
@@ -1107,7 +1108,7 @@ extern "rust-intrinsic" {
11071108
/// `write_bytes` is similar to C's [`memset`], but sets `count *
11081109
/// size_of::<T>()` bytes to `val`.
11091110
///
1110-
/// [`memset`]: https://www.gnu.org/software/libc/manual/html_node/Copying-Strings-and-Arrays.html#index-memset
1111+
/// [`memset`]: https://en.cppreference.com/w/c/string/byte/memset
11111112
///
11121113
/// # Safety
11131114
///
@@ -1158,8 +1159,14 @@ extern "rust-intrinsic" {
11581159
/// // At this point, using or dropping `v` results in undefined behavior.
11591160
/// // drop(v); // ERROR
11601161
///
1161-
/// // Leaking it does not invoke drop and is fine:
1162-
/// mem::forget(v)
1162+
/// // Even leaking `v` "uses" it, and henc eis undefined behavior.
1163+
/// // mem::forget(v); // ERROR
1164+
///
1165+
/// // Let us instead put in a valid value
1166+
/// ptr::write(&mut v, Box::new(42i32);
1167+
///
1168+
/// // Now the box is fine
1169+
/// assert_eq!(*v, 42);
11631170
/// ```
11641171
#[stable(feature = "rust1", since = "1.0.0")]
11651172
pub fn write_bytes<T>(dst: *mut T, val: u8, count: usize);

src/libcore/ptr.rs

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -8,8 +8,6 @@
88
// option. This file may not be copied, modified, or distributed
99
// except according to those terms.
1010

11-
// FIXME: talk about offset, copy_memory, copy_nonoverlapping_memory
12-
1311
//! Manually manage memory through raw pointers.
1412
//!
1513
//! *[See also the pointer primitive types](../../std/primitive.pointer.html).*
@@ -42,8 +40,10 @@
4240
//!
4341
//! ## Alignment
4442
//!
45-
//! Valid pointers are not necessarily properly aligned. However, most functions
46-
//! require their arguments to be properly aligned, and will explicitly state
43+
//! Valid pointers as defined above are not necessarily properly aligned (where
44+
//! "proper" alignment is defind by the pointee type, i.e., `*const T` must be
45+
//! aligned to `mem::align_of::<T>()`). However, most functions require their
46+
//! arguments to be properly aligned, and will explicitly state
4747
//! this requirement in their documentation. Notable exceptions to this are
4848
//! [`read_unaligned`] and [`write_unaligned`].
4949
//!
@@ -136,11 +136,12 @@ pub use intrinsics::write_bytes;
136136
/// let mut v = vec![Rc::new(0), last];
137137
///
138138
/// unsafe {
139+
/// // Shorten `v` to prevent the last item from being dropped. We do that first,
140+
/// // to prevent issues if the `drop_in_place` below panics.
141+
/// v.set_len(1);
139142
/// // Without a call `drop_in_place`, the last item would never be dropped,
140143
/// // and the memory it manages would be leaked.
141144
/// ptr::drop_in_place(&mut v[1]);
142-
/// // Shorten `v` to prevent the last item from being dropped.
143-
/// v.set_len(1);
144145
/// }
145146
///
146147
/// assert_eq!(v, &[0.into()]);
@@ -745,7 +746,7 @@ pub unsafe fn write<T>(dst: *mut T, src: T) {
745746
///
746747
/// unsafe {
747748
/// // Take a reference to a 32-bit integer which is not aligned.
748-
/// let unaligned = &mut x.unaligned;
749+
/// let unaligned = &mut x.unaligned as *mut u32;
749750
///
750751
/// // Dereferencing normally will emit an unaligned store instruction,
751752
/// // causing undefined behavior.

0 commit comments

Comments
 (0)