diff --git a/destructors.md b/destructors.md index 91abdab..1feb085 100644 --- a/destructors.md +++ b/destructors.md @@ -17,7 +17,7 @@ boilerplate" to drop children. If a struct has no special logic for being dropped other than dropping its children, then it means `Drop` doesn't need to be implemented at all! -**There is no stable way to prevent this behaviour in Rust 1.0.** +**There is no stable way to prevent this behavior in Rust 1.0.** Note that taking `&mut self` means that even if you could suppress recursive Drop, Rust will prevent you from e.g. moving fields out of self. For most types, @@ -101,7 +101,7 @@ After we deallocate the `box`'s ptr in SuperBox's destructor, Rust will happily proceed to tell the box to Drop itself and everything will blow up with use-after-frees and double-frees. -Note that the recursive drop behaviour applies to all structs and enums +Note that the recursive drop behavior applies to all structs and enums regardless of whether they implement Drop. Therefore something like ```rust diff --git a/drop-flags.md b/drop-flags.md index 5655c5d..cfceafe 100644 --- a/drop-flags.md +++ b/drop-flags.md @@ -40,7 +40,7 @@ y = x; // y was init; Drop y, overwrite it, and make x uninit! // x goes out of scope; x was uninit; do nothing. ``` -Similarly, branched code where all branches have the same behaviour with respect +Similarly, branched code where all branches have the same behavior with respect to initialization has static drop semantics: ```rust diff --git a/leaking.md b/leaking.md index 0441db2..445349b 100644 --- a/leaking.md +++ b/leaking.md @@ -93,13 +93,13 @@ println!("{}", vec[0]); This is pretty clearly Not Good. Unfortunately, we're kind've stuck between a rock and a hard place: maintaining consistent state at every step has an enormous cost (and would negate any benefits of the API). Failing to maintain -consistent state gives us Undefined Behaviour in safe code (making the API +consistent state gives us Undefined Behavior in safe code (making the API unsound). So what can we do? Well, we can pick a trivially consistent state: set the Vec's len to be 0 when we start the iteration, and fix it up if necessary in the destructor. That way, if everything executes like normal we get the desired -behaviour with minimal overhead. But if someone has the *audacity* to +behavior with minimal overhead. But if someone has the *audacity* to mem::forget us in the middle of the iteration, all that does is *leak even more* (and possibly leave the Vec in an unexpected but otherwise consistent state). Since we've accepted that mem::forget is safe, this is definitely safe. We call diff --git a/other-reprs.md b/other-reprs.md index 71da743..e361fbb 100644 --- a/other-reprs.md +++ b/other-reprs.md @@ -19,8 +19,8 @@ kept in mind. Due to its dual purpose as "for FFI" and "for layout control", `repr(C)` can be applied to types that will be nonsensical or problematic if passed through the FFI boundary. -* ZSTs are still zero-sized, even though this is not a standard behaviour in -C, and is explicitly contrary to the behaviour of an empty type in C++, which +* ZSTs are still zero-sized, even though this is not a standard behavior in +C, and is explicitly contrary to the behavior of an empty type in C++, which still consumes a byte of space. * DSTs, tuples, and tagged unions are not a concept in C and as such are never @@ -65,7 +65,7 @@ compiler might be able to paper over alignment issues with shifts and masks. However if you take a reference to a packed field, it's unlikely that the compiler will be able to emit code to avoid an unaligned load. -**[As of Rust 1.0 this can cause undefined behaviour.][ub loads]** +**[As of Rust 1.0 this can cause undefined behavior.][ub loads]** `repr(packed)` is not to be used lightly. Unless you have extreme requirements, this should not be used. diff --git a/repr-rust.md b/repr-rust.md index 85e17a9..effeaf8 100644 --- a/repr-rust.md +++ b/repr-rust.md @@ -6,7 +6,7 @@ value of alignment `n` must only be stored at an address that is a multiple of `n`. So alignment 2 means you must be stored at an even address, and 1 means that you can be stored anywhere. Alignment is at least 1, and always a power of 2. Most primitives are generally aligned to their size, although this is -platform-specific behaviour. In particular, on x86 `u64` and `f64` may be only +platform-specific behavior. In particular, on x86 `u64` and `f64` may be only aligned to 32 bits. A type's size must always be a multiple of its alignment. This ensures that an diff --git a/vec-zsts.md b/vec-zsts.md index 72e8a34..9b1abf3 100644 --- a/vec-zsts.md +++ b/vec-zsts.md @@ -5,7 +5,7 @@ It's time. We're going to fight the spectre that is zero-sized types. Safe Rust raw allocations, which are exactly the two things that care about zero-sized types. We need to be careful of two things: -* The raw allocator API has undefined behaviour if you pass in 0 for an +* The raw allocator API has undefined behavior if you pass in 0 for an allocation size. * raw pointer offsets are no-ops for zero-sized types, which will break our C-style pointer iterator.