From 3aebce766fc1b8e6edd84bab9517f48b0fd7f23f Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 15 Jul 2019 13:43:15 +0200 Subject: [PATCH] stronger exclusion of UB-ful programs --- personal/_posts/2019-07-14-uninit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/personal/_posts/2019-07-14-uninit.md b/personal/_posts/2019-07-14-uninit.md index c6ee054..c5043ff 100644 --- a/personal/_posts/2019-07-14-uninit.md +++ b/personal/_posts/2019-07-14-uninit.md @@ -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. -- 2.30.2