fix typos in examples READMEs

diff --git a/examples/04.temporal_safety/README.md b/examples/04.temporal_safety/README.md
index e326c7e..1079d64 100644
--- a/examples/04.temporal_safety/README.md
+++ b/examples/04.temporal_safety/README.md

@@ -15,7 +15,7 @@
 The first value is the address, which is the same in both.
 Everything else, shown in brackets, is the *capability metadata*.
 
-The only field that changes after three call to `free` is the *tag* or *valid* bit.
+The only field that changes after the call to `free` is the *tag* or *valid* bit.
 This is the bit that indicates whether this is a valid capability.
 When this bit is cleared, the CPU will not permit this pointer to be used to authorise any operations.
 Its fields can still be read, which is why the other lines are the same.

diff --git a/examples/08.memory_safety/README.md b/examples/08.memory_safety/README.md
index 4eb367e..9c9151f 100644
--- a/examples/08.memory_safety/README.md
+++ b/examples/08.memory_safety/README.md

@@ -9,8 +9,8 @@
 ## Spatial safety
 
 By "spatial safety" we mean that every memory allocation has a well-defined size/bounds, and it's incorrect to access memory outside of these bounds. 
-Every C/C++ pointer in our system is a bounded, unforgeable CHERI capability.Every C/C++ pointer in our system is a bounded unforgeable CHERI capability.
-Any dereference Any dereference outside of an allocation's bounds, whether adjacent to the allocation or far outside, will trap. of an allocation's bounds, whether adjacent to the allocation or far outside, will trap.
+Every C/C++ pointer in our system is a bounded, unforgeable CHERI capability.
+Any dereference outside of an allocation's bounds, whether adjacent to the allocation or far outside, will trap. of an allocation's bounds, whether adjacent to the allocation or far outside, will trap.
 This is enforced by the hardware and so the same guarantees apply to accesses from assembly code.
 This property is enforced at the architectural level.
 You can see examples for that in the cases for `StackLinearOverflow`, `HeapLinearOverflow`, and `HeapNonlinearOverflow`, [implemented](memory_safety_inner.cc:49) in the inner compartment.