From: Ralf Jung Date: Tue, 24 Jul 2018 21:35:23 +0000 (+0200) Subject: clarify the problem in the last section X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/680009b67a3d136072a7ad88d5ea49416a915693 clarify the problem in the last section --- diff --git a/ralf/_posts/2018-07-24-pointers-and-bytes.md b/ralf/_posts/2018-07-24-pointers-and-bytes.md index 29cc24e..5d7a40b 100644 --- a/ralf/_posts/2018-07-24-pointers-and-bytes.md +++ b/ralf/_posts/2018-07-24-pointers-and-bytes.md @@ -157,9 +157,14 @@ This is why pointers are not simple, either. I hope I made a convincing argument that integers are not the only data one has to consider when formally specifying low-level languages such as C++ or (the unsafe parts of) Rust. However, this means that a simple operation like loading a byte from memory cannot just return a `u8`. +Imagine we [implement `memcpy`](https://github.com/alexcrichton/rlibc/blob/defb486e765846417a8e73329e8c5196f1dca49a/src/lib.rs#L39) by loading (in turn) every byte of the source into some local variable `v`, and then storing it to the target. What if that byte is part of a pointer? When a pointer is a pair of allocation and offset, what is its first byte? -We cannot represent this as a `u8`. +We have to say what the value of `v` is, so we have to find some way to answer this question. +(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. +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 %} enum ByteV1 { @@ -168,12 +173,12 @@ enum ByteV1 { } {% endhighlight %} For example, a `PtrFragment(ptr, 0)` represents the first byte of `ptr`. -This way, we can "take apart" a pointer into the individual bytes that represent this pointer in memory, and assemble it back together. +This way, `memcpy` can "take apart" a pointer into the individual bytes that represent this pointer in memory, and copy them separately. On a 32bit architecture, the full value representing `ptr` consists of the following 4 bytes: ``` [PtrFragment(ptr, 0), PtrFragment(ptr, 1), PtrFragment(ptr, 2), PtrFragment(ptr, 3)] ``` -Such a representation supports performing all byte-level "data moving" operations on pointers, like implementing `memcpy` by copying one byte at a time. +Such a representation supports performing all byte-level "data moving" operations on pointers, which is sufficient for `memcpy`. Arithmetic or bit-level operations are not fully supported; as already mentioned above, that requires a more sophisticated pointer representation. ## Uninitialized Memory