tweak

diff --git a/personal/_posts/2018-07-24-pointers-and-bytes.md b/personal/_posts/2018-07-24-pointers-and-bytes.md
index 61ecc14c8f2f5ccb52ffc80f4c6f863fc4e1ec4d..defc2ecc48aa583ae92ba642a4cb034877fc4eac 100644 (file)
--- a/personal/_posts/2018-07-24-pointers-and-bytes.md
+++ b/personal/_posts/2018-07-24-pointers-and-bytes.md
@@ -43,7 +43,7 @@ First of all, it is not allowed to perform pointer arithmetic (like `&x[i]` does
 Our program violates this rule: `x[i]` is outside of `x`, so this is undefined behavior.
 To be clear: Just the *computation* of `x_ptr` is already UB, we don't even get to the part where we want to *use* this pointer![^1]
 
 Our program violates this rule: `x[i]` is outside of `x`, so this is undefined behavior.
 To be clear: Just the *computation* of `x_ptr` is already UB, we don't even get to the part where we want to *use* this pointer![^1]
 

-[^1]: It turns out that `y-x` is also undefined behavior because [one may only subtract pointers into the same allocation](https://timsong-cpp.github.io/cppwp/n4140/expr.add#6). However, we could use `i = ((size_t)y - (size_t)x)/sizeof(int)` to work around that.
+[^1]: It turns out that `i = y-x` is *also* undefined behavior because [one may only subtract pointers into the same allocation](https://timsong-cpp.github.io/cppwp/n4140/expr.add#6). However, we could use `i = ((size_t)y - (size_t)x)/sizeof(int)` to work around that.

 
 But we are not done yet: This rule has a special exception that we can exploit to our advantage.
 If the arithmetic ends up computing a pointer *just past* the end of an allocation, that computation is fine.
 
 But we are not done yet: This rule has a special exception that we can exploit to our advantage.
 If the arithmetic ends up computing a pointer *just past* the end of an allocation, that computation is fine.


@@ -199,8 +199,10 @@ Using `Uninit` instead of an arbitrary bit pattern means miri can, in a single e
 
 ## Conclusion
 
 
 ## Conclusion
 

-We have seen that 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`.
+We have seen that 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`.[^4]

 With this, I think we are ready to look at a first draft of my "2018 memory model" (working title ;) -- in the next post. :)
 <!-- If you have any questions, feel free to [ask in the forums]! -->
 
 With this, I think we are ready to look at a first draft of my "2018 memory model" (working title ;) -- in the next post. :)
 <!-- If you have any questions, feel free to [ask in the forums]! -->
 

+[^4]: And just to be clear, I am talking about a pointer or byte in the model of an optimized *programming language* here.  When modeling hardware, everything is different.
+

 #### Footnotes
 #### Footnotes