X-Git-Url: https://git.ralfj.de/web.git/blobdiff_plain/4fb0688c1bdca89c3e47307a0b3d82b63aaf8576..508b06122bb3fd9fac9e6cc84069a6cfe056a717:/ralf/_posts/2019-07-14-uninit.md diff --git a/ralf/_posts/2019-07-14-uninit.md b/ralf/_posts/2019-07-14-uninit.md index c6ee054..f925b79 100644 --- a/ralf/_posts/2019-07-14-uninit.md +++ b/ralf/_posts/2019-07-14-uninit.md @@ -54,7 +54,7 @@ However, if you [run the example](https://play.rust-lang.org/?version=stable&mod ## What *is* uninitialized memory? How is this possible? -The answer is that every byte in memory cannot just have a value in `0..256` (this is Rust/Ruby syntax for a left-inclusive right-exclusive range), it can also be "uninitialized". +The answer is that, in the "abstract machine" that is used to specify the behavior of our program, every byte in memory cannot just have a value in `0..256` (this is Rust/Ruby syntax for a left-inclusive right-exclusive range), it can also be "uninitialized". Memory *remembers* if you initialized it. The `x` that is passed to `always_return_true` is *not* the 8-bit representation of some number, it is an uninitialized byte. Performing operations such as comparison on uninitialized bytes is undefined behavior. @@ -69,7 +69,8 @@ So, one time we "look" at `x` it can be at least 150, and then when we look at i `x` was just uninitialized all the time. That explains why our compiled example program behaves the way it does. -When thinking about Rust (or C, or C++), you have to imagine that every byte in memory is either initialized to some value in `0..256`, or *uninitialized*. +When thinking about Rust (or C, or C++), you have to think in terms of an "abstract machine", not the real hardware you are using. +Imagine that every byte in memory is either initialized to some value in `0..256`, or *uninitialized*. You can think of memory as storing an `Option` at every location.[^pointers] When new memory gets allocated for a local variable (on the stack) or on the heap, there is actually nothing random happening, everything is completely deterministic: every single byte of this memory is marked as *uninitialized*. Every location stores a `None`. @@ -108,7 +109,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.