From 946038b2f9bbc233c3b9671c77141378f53c0f87 Mon Sep 17 00:00:00 2001 From: Arthur Milchior Date: Wed, 4 May 2022 10:22:55 +0200 Subject: [PATCH] "UB" vs "Undefined Behavior" (#349) --- src/exotic-sizes.md | 4 ++-- src/meet-safe-and-unsafe.md | 2 +- src/transmutes.md | 14 +++++++------- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/exotic-sizes.md b/src/exotic-sizes.md index 8ada0fb..0c59e2c 100644 --- a/src/exotic-sizes.md +++ b/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` 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 diff --git a/src/meet-safe-and-unsafe.md b/src/meet-safe-and-unsafe.md index d7ad923..49b0086 100644 --- a/src/meet-safe-and-unsafe.md +++ b/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 diff --git a/src/transmutes.md b/src/transmutes.md index 2109848..1f6d7d5 100644 --- a/src/transmutes.md +++ b/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