From 47c3cd0d346138c154f853c872464ca22c7ebc74 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sun, 14 Jul 2019 18:33:33 +0200 Subject: [PATCH 1/1] link from old post to new --- ralf/_posts/2018-07-24-pointers-and-bytes.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ralf/_posts/2018-07-24-pointers-and-bytes.md b/ralf/_posts/2018-07-24-pointers-and-bytes.md index 0496a5d..68a2cb0 100644 --- a/ralf/_posts/2018-07-24-pointers-and-bytes.md +++ b/ralf/_posts/2018-07-24-pointers-and-bytes.md @@ -237,6 +237,8 @@ Finally, `Uninit` is also a better choice for interpreters like miri. Such interpreters have a hard time dealing with operations of the form "just choose any of these values" (i.e., non-deterministic operations), because if they want to fully explore all possible program executions, that means they have to try every possible value. Using `Uninit` instead of an arbitrary bit pattern means miri can, in a single execution, reliably tell you if your programs uses uninitialized values incorrectly. +**Update:** Since writing this section, I have written an entire [post dedicated to uninitialized memory and "real hardware"]({% post_url 2019-07-14-uninit %}) with more details, examples and references. **/Update** + ## Conclusion We have seen that in languages like C++ and Rust (unlike on real hardware), pointers can be different even when they point to the same address, and that a byte is more than just a number in `0..256`. -- 2.30.2