X-Git-Url: https://git.ralfj.de/web.git/blobdiff_plain/d966a7f819c1f85cbe024ce66f1e28604f9bd658..cce7a39d255170e4315c5da78949491e07c1c1f9:/personal/_posts/2018-07-24-pointers-and-bytes.md?ds=inline

diff --git a/personal/_posts/2018-07-24-pointers-and-bytes.md b/personal/_posts/2018-07-24-pointers-and-bytes.md
index f3c9133..23371fe 100644
--- a/personal/_posts/2018-07-24-pointers-and-bytes.md
+++ b/personal/_posts/2018-07-24-pointers-and-bytes.md
@@ -1,6 +1,6 @@
 ---
 title: "Pointers Are Complicated, or: What's in a Byte?"
-categories: internship rust
+categories: internship rust programming
 forum: https://internals.rust-lang.org/t/pointers-are-complicated-or-whats-in-a-byte/8045
 ---
 
@@ -35,7 +35,7 @@ It would be beneficial to be able to optimize the final read of `y[0]` to just r
 C++ compilers regularly perform such optimizations as they are crucial for generating high-quality assembly.[^perf]
 The justification for this optimization is that writing to `x_ptr`, which points into `x`, cannot change `y`.
 
-[^perf]: To be fair, the are *claimed* to be crucial for generating high-quality assembly. The claim sounds plausible to me, but unfortunately, I do not know of a systematic study exploring the performance benefits of undefined behavior such as this.
+[^perf]: To be fair, the are *claimed* to be crucial for generating high-quality assembly. The claim sounds plausible to me, but unfortunately, I do not know of a systematic study exploring the performance benefits of such optimizations.
 
 However, given how low-level a language C++ is, we can actually break this assumption by setting `i` to `y-x`.
 Since `&x[i]` is the same as `x+i`, this means we are actually writing `23` to `&y[0]`.
@@ -79,7 +79,7 @@ It does *not* point at an actual element of another object *even if they have th
 
 The key point here is that just because `x_ptr` and `&y[0]` point to the same *address*, that does not make them *the same pointer*, i.e., they cannot be used interchangeably:
 `&y[0]` points to the first element of `y`; `x_ptr` points past the end of `x`.
-If we replace `*x_ptr = 23` by `*&y[0] = 0`, we change the meaning of the program, even though the two pointers have been tested for equality.
+If we replace `*x_ptr = 23` by `*&y[0] = 23`, we change the meaning of the program, even though the two pointers have been tested for equality.
 
 This is worth repeating: