From e62b5b8c8f92ba85cbbabe9e6208b44482b3a4a7 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 15 Aug 2024 11:32:16 +0200 Subject: [PATCH] don't capitalize Undefined Behavior --- src/behavior-considered-undefined.md | 2 +- src/expressions/operator-expr.md | 4 ++-- src/types/textual.md | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/behavior-considered-undefined.md b/src/behavior-considered-undefined.md index bee50109c..69c44bc4c 100644 --- a/src/behavior-considered-undefined.md +++ b/src/behavior-considered-undefined.md @@ -101,7 +101,7 @@ alignment 1). In other words, the alignment requirement derives from the type of the pointer that was dereferenced, *not* the type of the field that is being accessed. -Note that a place based on a misaligned pointer only leads to Undefined Behavior +Note that a place based on a misaligned pointer only leads to undefined behavior when it is loaded from or stored to. `addr_of!`/`addr_of_mut!` on such a place is allowed. `&`/`&mut` on a place requires the alignment of the field type (or else the program would be "producing an invalid value"), which generally is a diff --git a/src/expressions/operator-expr.md b/src/expressions/operator-expr.md index d3fa33b81..cd9e5e197 100644 --- a/src/expressions/operator-expr.md +++ b/src/expressions/operator-expr.md @@ -100,7 +100,7 @@ struct Packed { } let packed = Packed { f1: 1, f2: 2 }; -// `&packed.f2` would create an unaligned reference, and thus be Undefined Behavior! +// `&packed.f2` would create an unaligned reference, and thus be undefined behavior! let raw_f2 = ptr::addr_of!(packed.f2); assert_eq!(unsafe { raw_f2.read_unaligned() }, 2); ``` @@ -116,7 +116,7 @@ struct Demo { let mut uninit = MaybeUninit::::uninit(); // `&uninit.as_mut().field` would create a reference to an uninitialized `bool`, -// and thus be Undefined Behavior! +// and thus be undefined behavior! let f1_ptr = unsafe { ptr::addr_of_mut!((*uninit.as_mut_ptr()).field) }; unsafe { f1_ptr.write(true); } let init = unsafe { uninit.assume_init() }; diff --git a/src/types/textual.md b/src/types/textual.md index fcbec0823..a4765b523 100644 --- a/src/types/textual.md +++ b/src/types/textual.md @@ -4,7 +4,7 @@ The types `char` and `str` hold textual data. A value of type `char` is a [Unicode scalar value] (i.e. a code point that is not a surrogate), represented as a 32-bit unsigned word in the 0x0000 to 0xD7FF -or 0xE000 to 0x10FFFF range. It is immediate [Undefined Behavior] to create a +or 0xE000 to 0x10FFFF range. It is immediate [undefined behavior] to create a `char` that falls outside this range. A `[char]` is effectively a UCS-4 / UTF-32 string of length 1. @@ -12,7 +12,7 @@ A value of type `str` is represented the same way as `[u8]`, a slice of 8-bit unsigned bytes. However, the Rust standard library makes extra assumptions about `str`: methods working on `str` assume and ensure that the data in there is valid UTF-8. Calling a `str` method with a non-UTF-8 buffer can cause -[Undefined Behavior] now or in the future. +[undefined behavior] now or in the future. Since `str` is a [dynamically sized type], it can only be instantiated through a pointer type, such as `&str`. @@ -26,5 +26,5 @@ Every byte of a `char` is guaranteed to be initialized (in other words, some bit patterns are invalid `char`s, the inverse is not always sound). [Unicode scalar value]: http://www.unicode.org/glossary/#unicode_scalar_value -[Undefined Behavior]: ../behavior-considered-undefined.md +[undefined behavior]: ../behavior-considered-undefined.md [dynamically sized type]: ../dynamically-sized-types.md