@@ -70,14 +70,14 @@ pub use crate::intrinsics::transmute;
7070/// mem::forget(file);
7171/// ```
7272///
73- /// This is useful when the ownership of the underlying was previously
73+ /// This is useful when the ownership of the underlying resource was previously
7474/// transferred to code outside of Rust, for example by transmitting the raw
7575/// file descriptor to C code.
7676///
7777/// # Relationship with `ManuallyDrop`
7878///
79- /// Using `mem::forget` to transmit memory ownership is error-prone and is best
80- /// replaced with `ManuallyDrop`. Consider, for example, this code:
79+ /// While `mem::forget` can also be used to transfer * memory* ownership, doing so is error-prone.
80+ /// [ `ManuallyDrop`] should be used instead . Consider, for example, this code:
8181///
8282/// ```
8383/// use std::mem;
@@ -97,9 +97,9 @@ pub use crate::intrinsics::transmute;
9797/// `mem::forget()`, a panic within it would cause a double free because the same memory
9898/// is handled by both `v` and `s`.
9999/// * After calling `v.as_mut_ptr()` and transmitting the ownership of the data to `s`,
100- /// the `v` value is invalid. Although moving a value to `mem::forget` (which won't
101- /// inspect it) seems safe , some types have strict requirements on their values that
102- /// make them invalid when dangling or no longer owned. Using invalid values in any
100+ /// the `v` value is invalid. Even when a value is just moved to `mem::forget` (which won't
101+ /// inspect it), some types have strict requirements on their values that
102+ /// make them invalid when dangling or no longer owned. Using invalid values in any
103103/// way, including passing them to or returning them from functions, constitutes
104104/// undefined behavior and may break the assumptions made by the compiler.
105105///
@@ -123,11 +123,11 @@ pub use crate::intrinsics::transmute;
123123///
124124/// `ManuallyDrop` robustly prevents double-free because we disable `v`'s destructor
125125/// before doing anything else. `mem::forget()` doesn't allow this because it consumes its
126- /// argument, forcing us to call it only after extracting anything we need from `v`. Even
126+ /// argument, forcing us to call it only after extracting anything we need from `v`. Even
127127/// if a panic were introduced between construction of `ManuallyDrop` and building the
128128/// string (which cannot happen in the code as shown), it would result in a leak and not a
129129/// double free. In other words, `ManuallyDrop` errs on the side of leaking instead of
130- /// erring on the side of dropping.
130+ /// erring on the side of (double-) dropping.
131131///
132132/// Also, `ManuallyDrop` prevents us from having to "touch" `v` after transferring the
133133/// ownership to `s` - the final step of interacting with `v` to dispoe of it without
0 commit comments