Skip to content

Commit ecf7600

Browse files
authored
Merge pull request #1575 from RalfJung/ub
don't capitalize Undefined Behavior
2 parents 0dfd6b8 + e62b5b8 commit ecf7600

File tree

3 files changed

+6
-6
lines changed

3 files changed

+6
-6
lines changed

Diff for: src/behavior-considered-undefined.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -101,7 +101,7 @@ alignment 1). In other words, the alignment requirement derives from the type of
101101
the pointer that was dereferenced, *not* the type of the field that is being
102102
accessed.
103103

104-
Note that a place based on a misaligned pointer only leads to Undefined Behavior
104+
Note that a place based on a misaligned pointer only leads to undefined behavior
105105
when it is loaded from or stored to. `addr_of!`/`addr_of_mut!` on such a place
106106
is allowed. `&`/`&mut` on a place requires the alignment of the field type (or
107107
else the program would be "producing an invalid value"), which generally is a

Diff for: src/expressions/operator-expr.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -100,7 +100,7 @@ struct Packed {
100100
}
101101

102102
let packed = Packed { f1: 1, f2: 2 };
103-
// `&packed.f2` would create an unaligned reference, and thus be Undefined Behavior!
103+
// `&packed.f2` would create an unaligned reference, and thus be undefined behavior!
104104
let raw_f2 = ptr::addr_of!(packed.f2);
105105
assert_eq!(unsafe { raw_f2.read_unaligned() }, 2);
106106
```
@@ -116,7 +116,7 @@ struct Demo {
116116

117117
let mut uninit = MaybeUninit::<Demo>::uninit();
118118
// `&uninit.as_mut().field` would create a reference to an uninitialized `bool`,
119-
// and thus be Undefined Behavior!
119+
// and thus be undefined behavior!
120120
let f1_ptr = unsafe { ptr::addr_of_mut!((*uninit.as_mut_ptr()).field) };
121121
unsafe { f1_ptr.write(true); }
122122
let init = unsafe { uninit.assume_init() };

Diff for: src/types/textual.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -4,15 +4,15 @@ The types `char` and `str` hold textual data.
44

55
A value of type `char` is a [Unicode scalar value] (i.e. a code point that is
66
not a surrogate), represented as a 32-bit unsigned word in the 0x0000 to 0xD7FF
7-
or 0xE000 to 0x10FFFF range. It is immediate [Undefined Behavior] to create a
7+
or 0xE000 to 0x10FFFF range. It is immediate [undefined behavior] to create a
88
`char` that falls outside this range. A `[char]` is effectively a UCS-4 / UTF-32
99
string of length 1.
1010

1111
A value of type `str` is represented the same way as `[u8]`, a slice of
1212
8-bit unsigned bytes. However, the Rust standard library makes extra assumptions
1313
about `str`: methods working on `str` assume and ensure that the data in there
1414
is valid UTF-8. Calling a `str` method with a non-UTF-8 buffer can cause
15-
[Undefined Behavior] now or in the future.
15+
[undefined behavior] now or in the future.
1616

1717
Since `str` is a [dynamically sized type], it can only be instantiated through a
1818
pointer type, such as `&str`.
@@ -26,5 +26,5 @@ Every byte of a `char` is guaranteed to be initialized (in other words,
2626
some bit patterns are invalid `char`s, the inverse is not always sound).
2727

2828
[Unicode scalar value]: http://www.unicode.org/glossary/#unicode_scalar_value
29-
[Undefined Behavior]: ../behavior-considered-undefined.md
29+
[undefined behavior]: ../behavior-considered-undefined.md
3030
[dynamically sized type]: ../dynamically-sized-types.md

0 commit comments

Comments
 (0)