mention valgrind connection

diff --git a/ralf/_posts/2019-07-14-uninit.md b/ralf/_posts/2019-07-14-uninit.md
index 72b26c76ab5207fec12d8d5c3bdfbdff5b4ff9e1..314ca958e3e91a0522e0279ae798172c9242ac82 100644 (file)
--- a/ralf/_posts/2019-07-14-uninit.md
+++ b/ralf/_posts/2019-07-14-uninit.md
@@ -107,8 +107,11 @@ But *the Rust program you wrote does not run on your hardware*.
 It runs on the Rust abstract machine, and that machine (which only exists in our minds) *does* have a notion of "uninitialized memory".
 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).
 It runs on the Rust abstract machine, and that machine (which only exists in our minds) *does* have a notion of "uninitialized memory".
 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.
 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.
+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.

 
 This does not just apply to uninitialized memory: for example, in x86 assembly, there is no difference between "relaxed" and "release"/"acquire"-style atomic memory accesses.
 But when writing Rust programs, even when writing Rust programs that you only intend to compile to x86, "what the hardware does" just does not matter.
 
 This does not just apply to uninitialized memory: for example, in x86 assembly, there is no difference between "relaxed" and "release"/"acquire"-style atomic memory accesses.
 But when writing Rust programs, even when writing Rust programs that you only intend to compile to x86, "what the hardware does" just does not matter.