From: Ralf Jung Date: Wed, 25 Jul 2018 10:22:13 +0000 (+0200) Subject: clarify extra-hidden-state-in-memory X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/21c20a795de604bd871e859442273e302be25ce6?hp=1af9cc085fccb07e0f1aeb83e47d413b2adcf888 clarify extra-hidden-state-in-memory --- diff --git a/ralf/_posts/2018-07-24-pointers-and-bytes.md b/ralf/_posts/2018-07-24-pointers-and-bytes.md index dfd6bd1..5d6b60d 100644 --- a/ralf/_posts/2018-07-24-pointers-and-bytes.md +++ b/ralf/_posts/2018-07-24-pointers-and-bytes.md @@ -162,7 +162,8 @@ We have to say what the value of `v` is, so we have to find some way to answer t (And this is an entirely separate issue from the problem with multiplication that came up in the last section. We just assume some abstract type `Pointer`.) We cannot represent a byte of a pointer as an element of `0..256`. -Instead, we will remember both the pointer, and which byte of the pointer we got. +Essentially, if we use a naive model of memory, the extra "hidden" part of a pointer (the one that makes it more than just an integer) would be lost whne a pointer is stored to memory and loaded again. +We have to fix this, so we have to extend our notion of a "byte" to accomodate that extra state. So, a byte is now *either* an element of `0..256` ("raw bits"), *or* the n-th byte of some abstract pointer. If we were to implement our memory model in Rust, this might look as follows: {% highlight rust %}