more on pointers in integer variables
[web.git] / personal / _posts / 2017-05-23-internship-starting.md
index 149b4f38b0401be832e6336c1b29ada0fff7d780..b20c7c30560795a4be667d5ee9475693f4410fe9 100644 (file)
@@ -31,7 +31,7 @@ And finally, an interpreter can be used for testing:  We could actually check wh
 This will be very important while we are still developing the specification (to check whether our intuition for what should and should not be allowed matches the interpreter), but it is also extremely useful later for authors of unsafe code to check whether they are violating the rules we are going to put in place.
 
 Lucky enough, such an interpreter already exists: [miri](https://github.com/solson/miri)!
 This will be very important while we are still developing the specification (to check whether our intuition for what should and should not be allowed matches the interpreter), but it is also extremely useful later for authors of unsafe code to check whether they are violating the rules we are going to put in place.
 
 Lucky enough, such an interpreter already exists: [miri](https://github.com/solson/miri)!
-That's great, because it means I do not have to write an interpreter from scratch, defining what a stack is and how to perform integers operations and whatnot.
+That's great, because it means I do not have to write an interpreter from scratch, defining what a stack is and how to perform integer operations and whatnot.
 Instead, I can concentrate on the interesting questions coming up in the unsafe code guidelines:
 What exactly do the guarantees "mutable borrows don't have aliases" and "the pointees of shared borrows are not mutated" *mean*?  How should they be reflected in a semantics of MIR -- in miri -- such that the desired [optimizations](https://github.com/nikomatsakis/rust-memory-model/tree/master/optimizations) are actually legal, while at the same time the [unsafe code](https://doc.rust-lang.org/nomicon/) people write has the desired behavior?
 
 Instead, I can concentrate on the interesting questions coming up in the unsafe code guidelines:
 What exactly do the guarantees "mutable borrows don't have aliases" and "the pointees of shared borrows are not mutated" *mean*?  How should they be reflected in a semantics of MIR -- in miri -- such that the desired [optimizations](https://github.com/nikomatsakis/rust-memory-model/tree/master/optimizations) are actually legal, while at the same time the [unsafe code](https://doc.rust-lang.org/nomicon/) people write has the desired behavior?