Minor polish of the CHERI saga while catching up with it

phk, if any of this does not match your intentions, please just change it back.

waving from the boat...

doc/sphinx/phk/cheri1.rst

@@ -72,7 +72,7 @@ For those of you not familiar with Varnish, you will need to know:
 I still hate Autocrap tools
 ---------------------------
 
-Autocrap is a hack on a hack on hack which really ruins software
+Autocrap is a hack on a hack on a hack which really ruins software
 portability, but it is the "industry standard" so we use it also
 for Varnish, no matter how much I hate it.
 
@@ -133,7 +133,7 @@ so::
 
 The two typedefs ``uintptr_t`` and ``intptr_t`` are big enough to
 hold a pointer so that you can write "portable" code which
-does the kind the kind of integer-pointer-mis-math which
+does the kind of integer-pointer-mis-math which
 CHERI prevents you from doing.
 
 In theory we should not have any ``[u]intptr_t`` in Varnish,

doc/sphinx/phk/cheri6.rst

@@ -119,10 +119,10 @@ The only "proper" solution is to build some kind of datastructure:
 List, tree, hash, DB2 database, pick any poison you prefer, and
 search out the metadata pointer using the impotent pointer as key.
 Given that CHERI pointers are huge, it may be a better idea to embed
-a numeric index in the object and use that the key,
+a numeric index in the object and use that as the key.
 
 An important benefit of this »additional work« is that if your
-free-function get passed a pointer to something else, you will
+free-function gets passed a pointer to something else, you will
 find out, because it is not in your data-structure.
 
 It would be a good idea if CHERI came with a quality implementation