clarify

diff --git a/ralf/_posts/2019-07-14-uninit.md b/ralf/_posts/2019-07-14-uninit.md
index 85c8dcba53f0008b64b0c33ba996c6c0d37bce37..0b16076ef830ffab220f19e64001cf40d5c1a213 100644 (file)
--- a/ralf/_posts/2019-07-14-uninit.md
+++ b/ralf/_posts/2019-07-14-uninit.md
@@ -60,7 +60,7 @@ The `x` that is passed to `always_return_true` is *not* the 8-bit representation
 Performing operations such as comparison on uninitialized bytes is [undefined behavior]({% post_url 2017-07-14-undefined-behavior %}).
 As a consequence, our program has undefined behavior, so we should not be surprised that it acts "weirdly".
 
 Performing operations such as comparison on uninitialized bytes is [undefined behavior]({% post_url 2017-07-14-undefined-behavior %}).
 As a consequence, our program has undefined behavior, so we should not be surprised that it acts "weirdly".
 

-Of course, there is a reason for this undefined behavior.
+Of course, there is a reason for this undefined behavior; there is a reason the "abstract machine" is defined the way it is.

 Compilers don't just want to annoy programmers.
 Ruling out operations such as comparison on uninitialized data is useful, because it means the compiler does not have to "remember" which exact bit pattern an uninitialized variable has!
 A well-behaved (UB-free) program cannot observe that bit pattern anyway.
 Compilers don't just want to annoy programmers.
 Ruling out operations such as comparison on uninitialized data is useful, because it means the compiler does not have to "remember" which exact bit pattern an uninitialized variable has!
 A well-behaved (UB-free) program cannot observe that bit pattern anyway.