link to LLVM doc; mention bitfields

diff --git a/personal/_posts/2019-07-14-uninit.md b/personal/_posts/2019-07-14-uninit.md
index f925b796096e0b537569be1361a4bc49ce64a626..1847e5eb5e6905e86d3dbbcc125bbe3e6d158fd0 100644 (file)
--- a/personal/_posts/2019-07-14-uninit.md
+++ b/personal/_posts/2019-07-14-uninit.md
@@ -65,6 +65,7 @@ Compilers don't just want to annoy programmers.
 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!
 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!

+[This LLVM document](http://nondot.org/sabre/LLVMNotes/UndefinedValue.txt) gives some more motivation for "unstable" uninitialized memory.

 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.
 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.


@@ -78,7 +79,7 @@ Every location stores a `None`.
 
 When writing safe Rust, you do not have to worry about this, but this is the model you should have in your head when dealing with uninitialized memory in unsafe code.
 Alexis wrote a [great post](https://gankro.github.io/blah/initialize-me-maybe/) on which APIs to use for that in Rust; there is no need for me to repeat all that here.
 
 When writing safe Rust, you do not have to worry about this, but this is the model you should have in your head when dealing with uninitialized memory in unsafe code.
 Alexis wrote a [great post](https://gankro.github.io/blah/initialize-me-maybe/) on which APIs to use for that in Rust; there is no need for me to repeat all that here.

-(In that post, Alexis says that every *bit* can be either 0, 1 or uninitialized, as opposed to every *byte* being initialized or not. Given that memory accesses happen at byte granularity, these two models are actually equivalent.)
+(In that post, Alexis says that every *bit* can be either 0, 1 or uninitialized, as opposed to every *byte* being initialized or not. Given that memory accesses happen at byte granularity, these two models are actually equivalent, at least in Rust which does not have C-style bitfields.)

 
 [^pointers]: In fact, [bytes are even more complicated than that]({% post_url 2018-07-24-pointers-and-bytes %}), but that is another topic.
 
 
 [^pointers]: In fact, [bytes are even more complicated than that]({% post_url 2018-07-24-pointers-and-bytes %}), but that is another topic.