Add revision for Chapter 7

Chapters/01-memory.qmd

@@ -20,7 +20,7 @@ knitr::opts_chunk$set(
 
 
 In this chapter, we will talk about memory. How does Zig controls memory? What
-commom tools are used? Are there any important aspect that makes memory
+common tools are used? Are there any important aspect that makes memory
 different/special in Zig? You will find the answers here.
 
 Every computer needs memory. Is by having memory that computers can temporarily store
@@ -153,7 +153,7 @@ probably have heard of the "duel" between Stack vs Heap. These are two different
 or different memory spaces, which are both available in Zig.
 
 These two types of memory don't actually duel with
-each other. This is a commom mistake that beginners have, when seeing "x vs y" styles of
+each other. This is a common mistake that beginners have, when seeing "x vs y" styles of
 tabloid headlines. These two types of memory are actually complementary to each other.
 So, in almost every Zig program that you ever write, you will likely use a combination of both.
 I will describe each memory space in detail over the next sections. But for now, I just want to
@@ -461,7 +461,7 @@ a space in the stack is reserved for this function call. But the stack
 have a key limitation which is: every object stored in the stack have a
 known fixed length.
 
-But in reality, there are two very commom instances where this "fixed length limitation" of the stack is a deal braker:
+But in reality, there are two very common instances where this "fixed length limitation" of the stack is a deal braker:
 
 1. the objects that you create inside your function might grow in size during the execution of the function.
 
@@ -473,7 +473,7 @@ stack. However, if this object is stored in the heap, then, you can return a poi
 end of the function. Because you (the programmer) control the lyfetime of any heap memory that you allocate. You decide
 when this memory get's destroyed/freed.
 
-These are commom situations where the stack is not good for.
+These are common situations where the stack is not good for.
 That is why you need a different memory management strategy to
 store these objects inside your function. You need to use
 a memory type that can grow together with your objects, or that you

Chapters/01-zig-weird.qmd

@@ -765,15 +765,15 @@ _ = ns; _ = ls;
 Is worth noting that these are static arrays, meaning that
 they cannot grow in size.
 Once you declare your array, you cannot change the size of it.
-This is very commom in low level languages.
+This is very common in low level languages.
 Because low level languages normally wants to give you (the programmer) full control over memory,
 and the way in which arrays are expanded is tightly related to
 memory management.
 
 
 ### Selecting elements of the array {#sec-select-array-elem}
 
-One very commom activity is to select specific portions of an array
+One very common activity is to select specific portions of an array
 you have in your source code.
 In Zig, you can select a specific element from your
 array, by simply providing the index of this particular
@@ -1302,7 +1302,7 @@ got codepoint E382AB
 ```
 
 
-### Some useful functions for strings
+### Some useful functions for strings {#sec-strings-useful-funs}
 
 In this section, I just want to quickly describe some functions from the Zig Standard Library
 that are very useful to use when working with strings. Most notably:

Chapters/03-structs.qmd

@@ -804,7 +804,7 @@ of an existing object.
 If the compiler do find such type annotation, then, it will use this
 type in your literal struct.
 
-Anonymous structs are very commom to be used as inputs to function arguments in Zig.
+Anonymous structs are very common to be used as inputs to function arguments in Zig.
 One example that you have seen already constantly, is the `print()`
 function from the `stdout` object.
 This function takes two arguments.
@@ -1073,7 +1073,7 @@ as you would expect from a traditional strongly typed language, such as C and C+
 
 In some situations, the `zig` compiler can use type inference to solves the data types for you, easing some of
 the burden that you carry as a developer.
-The most commom way this happens is through function arguments that receives struct objects
+The most common way this happens is through function arguments that receives struct objects
 as input.
 
 In general, type inference in Zig is done by using the dot character (`.`).
@@ -1089,7 +1089,7 @@ This type inference is done by looking for some minimal hint of the correct data
 You could say that the `zig` compiler looks for any neighbouring type annotation that might tell him
 what would be the correct type.
 
-Another commom place where we use type inference in Zig is at switch statements (which we talk about at @sec-switch).
+Another common place where we use type inference in Zig is at switch statements (which we talk about at @sec-switch).
 I also gave some other examples of type inference at @sec-switch, where we were inferring the data types of enum values listed inside
 of switch statements (e.g. `.DE`).
 But as another example, take a look at this `fence()` function reproduced below,

Chapters/03-unittests.qmd

@@ -175,7 +175,7 @@ Test [1/1] leak_memory.test.memory leak...
 
 ## Testing errors
 
-One commom style of unit tests are those that look for
+One common style of unit tests are those that look for
 specific errors in your functions. In other words, you write
 a unit test that tries to assert if a specific function call
 returns any error, or a specific type of error.