projects: sort alphabetically

[web.git] / personal / _posts / 2020-12-14-provenance.md

diff --git a/personal/_posts/2020-12-14-provenance.md b/personal/_posts/2020-12-14-provenance.md
index b591c00e8751a14162a89ccc8baf723e6af82029..94040c417cecb1e86a83942f6530cd8fb0b22a2c 100644 (file)
--- a/personal/_posts/2020-12-14-provenance.md
+++ b/personal/_posts/2020-12-14-provenance.md
@@ -1,6 +1,6 @@
 ---
 title: "Pointers Are Complicated II, or: We need better language specs"
 ---
 title: "Pointers Are Complicated II, or: We need better language specs"

-categories: rust research
+categories: rust research programming

 forum: https://internals.rust-lang.org/t/pointers-are-complicated-ii-or-we-need-better-language-specs/13562
 license: CC BY-SA 4.0
 license-url: https://creativecommons.org/licenses/by-sa/4.0/
 forum: https://internals.rust-lang.org/t/pointers-are-complicated-ii-or-we-need-better-language-specs/13562
 license: CC BY-SA 4.0
 license-url: https://creativecommons.org/licenses/by-sa/4.0/


@@ -59,7 +59,7 @@ However, after the desired optimization, the program now causes a signed integer
 
 [^loop]: If you are a regular reader of my blog, you will recognize this as the same optimization that already played a crucial role in [a previous post of mine]({% post_url 2020-07-15-unused-data %}). Loop-invariant code motion is a great optimization to look at when considering corner cases of IR semantics.
 
 
 [^loop]: If you are a regular reader of my blog, you will recognize this as the same optimization that already played a crucial role in [a previous post of mine]({% post_url 2020-07-15-unused-data %}). Loop-invariant code motion is a great optimization to look at when considering corner cases of IR semantics.
 

-[^signed-int-overflow]: If you are coming here from Rust, imagine `i + j` was written as `i.unchecked_add(j)`.
+[^signed-int-overflow]: If you are coming here with a Rust mindset, imagine `i + j` was written as `i.unchecked_add(j)`.

 
 One might be tempted to ignore this problem because the UB on integer overflow is a compiler-only concept; every target supported by the compiler will do the obvious thing and just produce an overflowing result.
 However, there might be other compiler passes running after the optimization we are considering.
 
 One might be tempted to ignore this problem because the UB on integer overflow is a compiler-only concept; every target supported by the compiler will do the obvious thing and just produce an overflowing result.
 However, there might be other compiler passes running after the optimization we are considering.