Skip to content

Commit 7554341

Browse files
hniksicRalfJung
andcommitted
Minor re-wordings and typo fixes.
Co-Authored-By: Ralf Jung <[email protected]>
1 parent 2a08b0e commit 7554341

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

src/libcore/mem/mod.rs

+8-8
Original file line numberDiff line numberDiff line change
@@ -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

Comments
 (0)