chore: make some documents clearer (#528)

Author: wyrapeseed

c/blake3.h

@@ -38,7 +38,7 @@ extern "C" {
 #define BLAKE3_MAX_DEPTH 54
 
 // This struct is a private implementation detail. It has to be here because
-// it's part of blake3_hasher below.
+// it's part of the blake3_hasher structure defined below.
 typedef struct {
   uint32_t cv[8];
   uint64_t chunk_counter;

src/hazmat.rs

@@ -335,9 +335,9 @@ fn test_max_subtree_len() {
 /// than `input_len`. This leads to a tree where all left subtrees are "complete" and at least as
 /// large as their sibling right subtrees, as specified in section 2.1 of [the BLAKE3
 /// paper](https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf). For example, if an
-/// input is exactly two chunks, its left and right subtrees both get one chunk. But if an input is
-/// two chunks plus one more byte, then its left subtree gets two chunks, and its right subtree
-/// only gets one byte.
+/// input is exactly two chunks, the left subtree gets the first chunk and the right subtree gets
+/// the second chunk. But if an input is two chunks plus one more byte, then its left subtree gets
+/// two chunks, and its right subtree only gets one byte.
 ///
 /// This function isn't meaningful for one chunk of input, because chunks don't have children. It
 /// currently panics in debug mode if `input_len <= CHUNK_LEN`.

src/test.rs

@@ -982,7 +982,7 @@ fn test_serde() {
     // Version 1.5.2 of this crate changed the default serialization format to a bytestring
     // (instead of an array/list) to save bytes on the wire. That was a backwards compatibility
     // mistake for non-self-describing formats, and it's been reverted. Since some small number of
-    // serialized bytestrings will probably exist forever in the wild, we shold test that we can
+    // serialized bytestrings will probably exist forever in the wild, we should test that we can
     // still deserialize these from self-describing formats.
     let bytestring_cbor: &[u8] = &[
         0x58, 0x20, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe,