"UB" vs "Undefined Behavior"

The first occurrence of "UB" appeared without being ever introduced as an
abbreviation. It took me some time to get what it means. It was not had, but I
suspect that the space it wins in a manual is not worth its use here, so I
suggest to replace it by the two words.

However, I also suggest introduce this abbreviation explicitly, which will
prepare people who join some unsafe Rust discussion outside of this book.

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,
-  note that the Rust optimizer is free to assume that a shared reference won't
-  change through its lifetime and thus such transmutation will run afoul of those
-  assumptions. So:
-  * Transmuting an `&` to `&mut` is *always* UB.
+* Transmuting an `&` to `&mut` is Undefined Behavior. While certain usages may
+  *appear* safe, note that the Rust optimizer is free to assume that a shared
+  reference won't change through its lifetime and thus such transmutation will
+  run afoul of those assumptions. So:
+  * 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
-  (see above).
+  get filled with the wrong data, which will make you unhappy and can also be
+  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