forgot to add POPL to RustBelt publication

[web.git] / ralf / _posts / 2016-01-09-the-scope-of-unsafe.md

diff --git a/ralf/_posts/2016-01-09-the-scope-of-unsafe.md b/ralf/_posts/2016-01-09-the-scope-of-unsafe.md
index 757bd738ca155ea2402454551dd0bec225e04eed..59a318b3ac1226b3fdcc1bbd907b893b4396f92d 100644 (file)
--- a/ralf/_posts/2016-01-09-the-scope-of-unsafe.md
+++ b/ralf/_posts/2016-01-09-the-scope-of-unsafe.md
@@ -51,7 +51,7 @@ Oops!
 
 So, this example clearly shows that to evaluate the safety of types like `Vec`, we have to look at *every single function* provided by that data structure, even if it does not contain any `unsafe` code.
 
-## The reason why
+## The Reason Why
 
 Why is it the case that a safe function can break `Vec`?
 How can we even say that it is the safe function which is at fault, rather than some piece of `unsafe` code elsewhere in `Vec`?
@@ -74,7 +74,7 @@ Even academic researchers working on Rust got this wrong, arguing that in order
 That's why I think it's worth dedicating an entire blog post to this point.
 But we are not done yet, we can actually use this observation to learn more about types and type systems.
 
-## The semantic perspective
+## The Semantic Perspective
 
 There is another way to phrase the intuition of types having additional invariants:
 
@@ -129,7 +129,7 @@ This is just as bad as a function assigning `*f = 42u32` to a `f: &mut f32`.
 The difference between `Vec` and `MyType` is no less significant than the difference between `f32` and `u32`.
 It's just that the compiler has been specifically taught about `f32`, while it doesn't know enough about the semantics of `Vec`.
 
-## The actual scope of unsafe
+## The Actual Scope of Unsafe
 
 At this point, you may be slightly worried about the safety of the Rust ecosystem.
 I just spent two sections arguing that the Rust compiler actually doesn't know what it is doing when it comes to checking functions that work on `Vec`.