## 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.
Ruling out operations such as comparison on uninitialized data is useful, because it means the compiler does not have to "remember" which exact bit pattern an uninitialized variable has!
A well-behaved (UB-free) program cannot observe that bit pattern anyway.
So each time an uninitialized variable gets used, we can just use *any* machine register---and for different uses, those can be different registers!
-So, one time we "look" at `x` it can be at least 150, and then when we look at it again it is less than 120, even though `x` did not change.
+So, one time we "look" at `x` it can be at least 150, and then when we look at it again it is at most 120, even though `x` did not change.
`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<u8>` 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`.
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.
projects / web.git / blobdiff