"UB" vs "Undefined Behavior" (#349)

src/exotic-sizes.md

@@ -135,7 +135,7 @@ In principle, Rust can do some interesting analyses and optimizations based
 on this fact. For instance, `Result<T, Void>` is represented as just `T`,
 because the `Err` case doesn't actually exist (strictly speaking, this is only
 an optimization that is not guaranteed, so for example transmuting one into the
-other is still UB).
+other is still Undefined Behavior).
 
 The following *could* also compile:
 
@@ -165,7 +165,7 @@ construct.
 `*const ()` (or equivalent) works reasonably well for `void*`, and can be made
 into a reference without any safety problems. It still doesn't prevent you from
 trying to read or write values, but at least it compiles to a no-op instead
-of UB.
+of Undefined Behavior.
 
 ## Extern Types
 

src/meet-safe-and-unsafe.md

@@ -41,7 +41,7 @@ do, but we'll do anyway.
 Safe Rust is the *true* Rust programming language. If all you do is write Safe
 Rust, you will never have to worry about type-safety or memory-safety. You will
 never endure a dangling pointer, a use-after-free, or any other kind of
-Undefined Behavior.
+Undefined Behavior (a.k.a. UB).
 
 The standard library also gives you enough utilities out of the box that you'll
 be able to write high-performance applications and libraries in pure idiomatic

src/transmutes.md

@@ -19,11 +19,11 @@ boggling.
 * Transmute has an overloaded return type. If you do not specify the return type
   it may produce a surprising type to satisfy inference.
 
-* Transmuting an `&` to `&mut` is UB. While certain usages may *appear* safe,
+* Transmuting an `&` to `&mut` is Undefined Behavior. While certain usages may
-  note that the Rust optimizer is free to assume that a shared reference won't
+  *appear* safe, note that the Rust optimizer is free to assume that a shared
-  change through its lifetime and thus such transmutation will run afoul of those
+  reference won't change through its lifetime and thus such transmutation will
-  assumptions. So:
+  run afoul of those assumptions. So:
-  * Transmuting an `&` to `&mut` is *always* UB.
+  * Transmuting an `&` to `&mut` is *always* Undefined Behavior.
   * No you can't do it.
   * No you're not special.
 
@@ -32,8 +32,8 @@ boggling.
 
 * When transmuting between different compound types, you have to make sure they
   are laid out the same way! If layouts differ, the wrong fields are going to
-  get filled with the wrong data, which will make you unhappy and can also be UB
+  get filled with the wrong data, which will make you unhappy and can also be
-  (see above).
+  Undefined Behavior (see above).
 
   So how do you know if the layouts are the same? For `repr(C)` types and
   `repr(transparent)` types, layout is precisely defined. But for your