add some comments to code snippets

[web.git] / ralf / _posts / 2022-04-11-provenance-exposed.md

diff --git a/ralf/_posts/2022-04-11-provenance-exposed.md b/ralf/_posts/2022-04-11-provenance-exposed.md
index 56c7f8f71b04124b9271bb3dda72bb269957b7fb..5265df60efbcfa4da7b7f33fed1498eed98d0b83 100644 (file)
--- a/ralf/_posts/2022-04-11-provenance-exposed.md
+++ b/ralf/_posts/2022-04-11-provenance-exposed.md
@@ -78,7 +78,7 @@ static int uwu(int *restrict x, int *restrict y) {
 
   int *y2 = y-1;
   uintptr_t y2addr = (uintptr_t)y2;
-  int *ptr = (int*)y2addr;
+  int *ptr = (int*)y2addr; // <-- using y2addr
   *ptr = 1;
 
   return *x;
@@ -104,12 +104,12 @@ static int uwu(int *restrict x, int *restrict y) {
   int *ptr = (int*)y2addr;
   *ptr = 1;
 
-  return 0;
+  return 0; // <-- hard-coded return value
 }
 
 int main() {
-  int i = 0;
-  int res = uwu(&i, &i);
+  int i[2] = {0, 0};
+  int res = uwu(&i[0], &i[1]);
   // Now this prints 0!
   printf("%d\n", res);
 }
@@ -419,7 +419,7 @@ I discussed above how my vision for Rust relates to the direction C is moving to
 What does that mean for the design space of LLVM?
 Which changes need to be made to fix (potential) miscompilations in LLVM and to make it compatible with these ideas for C and/or Rust?
 Here's the list of open problems I am aware of:
-- LLVM needs to stop [removing `inttoptr(ptrtoint(_))`](https://bugs.llvm.org/show_bug.cgi?id=34548) and stop doing [replacement of `==`-equal pointers](https://bugs.llvm.org/show_bug.cgi?id=35229).
+- LLVM needs to stop [removing `inttoptr(ptrtoint(_))`](https://github.com/llvm/llvm-project/issues/33896) and stop doing [replacement of `==`-equal pointers](https://github.com/llvm/llvm-project/issues/34577).
 - As the first example shows, LLVM also needs to treat `ptrtoint` as a side-effecting operation that has to be kept around even when its result is unused. (Of course, as with everything I say here, there can be special cases where the old optimizations are still correct, but they need extra justification.)
 - I think LLVM should also treat `inttoptr` as a side-effecting (and, in particular, non-deterministic) operation, as per the last example. However, this could possibly be avoided with a `noalias` model that specifically accounts for new kinds of provenance being synthesized by casts. (I am being vague here since I don't know what that provenance needs to look like.)