From 8ed857c95b62379873a4c0dc92b5999386834030 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 31 Jul 2018 14:12:26 +0200 Subject: [PATCH 1/1] typo --- personal/_posts/2018-07-24-pointers-and-bytes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/personal/_posts/2018-07-24-pointers-and-bytes.md b/personal/_posts/2018-07-24-pointers-and-bytes.md index 35a5c15..0496a5d 100644 --- a/personal/_posts/2018-07-24-pointers-and-bytes.md +++ b/personal/_posts/2018-07-24-pointers-and-bytes.md @@ -173,7 +173,7 @@ 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`. -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. +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 when 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: -- 2.30.2