X-Git-Url: https://git.ralfj.de/web.git/blobdiff_plain/cd545f1d8766d3326725bca9e3cc898eeac387fd..0d24e06d62c704c81568dbc2a50020522330ad88:/personal/_posts/2019-07-14-uninit.md?ds=inline

diff --git a/personal/_posts/2019-07-14-uninit.md b/personal/_posts/2019-07-14-uninit.md
index 0b16076..7d056c7 100644
--- a/personal/_posts/2019-07-14-uninit.md
+++ b/personal/_posts/2019-07-14-uninit.md
@@ -54,7 +54,7 @@ However, if you [run the example](https://play.rust-lang.org/?version=stable&mod
 ## What *is* uninitialized memory?
 
 How is this possible?
-The answer is that, in the "abstract machine" that is used to specify the behavior of our program, every byte in memory cannot just have a value in `0..256` (this is Rust/Ruby syntax for a left-inclusive right-exclusive range), it can also be "uninitialized".
+The answer is that, in the "abstract machine" that is used to specify the behavior of our program, every byte in memory cannot just have a value in `0..256` (this is Rust syntax for a left-inclusive right-exclusive range), it can also be "uninitialized".
 Memory *remembers* if you initialized it.
 The `x` that is passed to `always_return_true` is *not* the 8-bit representation of some number, it is an uninitialized byte.
 Performing operations such as comparison on uninitialized bytes is [undefined behavior]({% post_url 2017-07-14-undefined-behavior %}).
@@ -122,7 +122,7 @@ The Rust abstract machine *does* make a distinction between "relaxed" and "relea
 After all, x86 does not have "uninitialized bytes" either, and still our example program above went wrong.
 
 Of course, to explain *why* the abstract machine is defined the way it is, we have to look at optimizations and hardware-level concerns.
-But without an abstract machine, it is very hard to ensure that all the optimizations a compiler performs are consistent---in fact, both [LLVM](https://bugs.llvm.org/show_bug.cgi?id=35229) and [GCC](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752) suffer from miscompilations caused by combining optimizations that all seem fine in isolation, but together cause incorrect code generation.
+But without an abstract machine, it is very hard to ensure that all the optimizations a compiler performs are consistent---in fact, both [LLVM](https://bugs.llvm.org/show_bug.cgi?id=35229) and [GCC](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752) suffer from miscompilations caused by combining optimizations that all seem [fine in isolation, but together cause incorrect code generation]({% post_url 2020-12-14-provenance %}).
 The abstract machine is needed as an ultimate arbiter that determines which optimizations can be safely combined with each other.
 I also think that when writing unsafe code, it is much easier to keep in your head a fixed abstract machine as opposed to a set of optimizations that might change any time, and might or might not be applied in any order.