stronger exclusion of UB-ful programs
authorRalf Jung <post@ralfj.de>
Mon, 15 Jul 2019 11:43:15 +0000 (13:43 +0200)
committerRalf Jung <post@ralfj.de>
Mon, 15 Jul 2019 11:43:15 +0000 (13:43 +0200)
ralf/_posts/2019-07-14-uninit.md

index c6ee054c28086e3c4578420fb5d33b331d88cdb3..c5043ff1bf7925ba584fcfe0cd3092634c1e866a 100644 (file)
@@ -108,7 +108,7 @@ It runs on the Rust abstract machine, and that machine (which only exists in our
 The real, physical hardware that we end up running the compiled program on is a very efficient *but imprecise* implementation of this abstract machine, and all the rules that Rust has for undefined behavior work together to make sure that this imprecision is not visible for *well-behaved* (UB-free) programs.
 But for programs that do have UB, this "illusion" breaks down, and [anything is possible](https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html).
 
-UB-free programs can be made sense of by looking at their assembly, but *whether* a program has UB is impossible to tell on that level.
+*Only* UB-free programs can be made sense of by looking at their assembly, but *whether* a program has UB is impossible to tell on that level.
 For that, you need to think in terms of the abstract machine.[^sanitizer]
 
 [^sanitizer]: This does imply that tools like valgrind, that work on the final assembly, can never reliably detect *all* UB.