link to my UB post
authorRalf Jung <post@ralfj.de>
Mon, 15 Jul 2019 12:58:59 +0000 (14:58 +0200)
committerRalf Jung <post@ralfj.de>
Mon, 15 Jul 2019 12:58:59 +0000 (14:58 +0200)
ralf/_posts/2019-07-14-uninit.md

index e2089cb9ca09f42d97db73203f6ca40bc78e24f5..c8f2d9da050f2222bb813f9442cfa605d4e769c0 100644 (file)
@@ -57,7 +57,7 @@ How is this possible?
 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.
 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.
+Performing operations such as comparison on uninitialized bytes is [undefined behavior]({% post_url 2017-07-14-undefined-behavior %}).
 As a consequence, our program has undefined behavior, so we should not be surprised that it acts "weirdly".
 
 Of course, there is a reason for this undefined behavior.
 As a consequence, our program has undefined behavior, so we should not be surprised that it acts "weirdly".
 
 Of course, there is a reason for this undefined behavior.