From fbef74eb0dbd88e4fc4172a18c09ef084c9d9ef2 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 15 Jul 2019 13:28:21 +0200 Subject: [PATCH] more precise about what the HW does --- personal/_posts/2019-07-14-uninit.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/personal/_posts/2019-07-14-uninit.md b/personal/_posts/2019-07-14-uninit.md index a5656b4..72b26c7 100644 --- a/personal/_posts/2019-07-14-uninit.md +++ b/personal/_posts/2019-07-14-uninit.md @@ -101,12 +101,14 @@ At least for LLVM, that [might change though](http://www.cs.utah.edu/~regehr/pap ## "What the hardware does" considered harmful -Maybe the most important lesson to take away from this post is that "what the hardware does" is most of the time *irrelevant* when discussing what a Rust/C/C++ program does. +Maybe the most important lesson to take away from this post is that "what the hardware does" is most of the time *irrelevant* when discussing what a Rust/C/C++ program does, unless you *already established that there is no undefined behavior*. Sure, hardware (well, [most hardware](https://devblogs.microsoft.com/oldnewthing/20040119-00/?p=41003)) does not have a notion of "uninitialized memory". 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). +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. 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. -- 2.30.2