[SPCA] Fixes a few errors

semester3/spca/parts/00_asm/01_syntax/00_intro.tex

@@ -1,6 +1,8 @@
 \newpage
 \subsection{The syntax}
-There are two common styles: AT\&T syntax (common on UNIX) and Intel syntax (common on Windows)
+There are two common styles: AT\&T syntax (common on UNIX) and Intel syntax (common on Windows).
+The most obvious difference between the two is that they invert the order of operands,
+i.e. where the AT\&T syntax has the destination as the second argument, the Intel syntax puts it first.
 
 The state that is visible to us is:
 \begin{itemize}

semester3/spca/parts/00_asm/02_dtype-dstruct/00_data-types.tex

@@ -1,6 +1,6 @@
 \subsection{Data types}
 Assembly supports the following integer types (where GAS stands for GNU Assembly).
-If they are signed or unsigned does not matter (as we have seen), so it's up to you to interpret them as one or the other
+If they are signed or unsigned does not matter (as we will see in section \ref{sec:c-integers}), so it's up to you to interpret them as one or the other
 \begin{tables}{llll}{Intel & GAS        & Bytes & \lC}
               byte         & \texttt{b} & 1     & \texttt{[unsigned] char}  \\
               word         & \texttt{w} & 2     & \texttt{[unsigned] short} \\
@@ -15,5 +15,5 @@ They are stored and operated on in floating point registers.
               double       & \texttt{l} & 8     & \texttt{double} \\
               extended     & \texttt{t} & 16     & \texttt{long double} \\
 \end{tables}
-Assembly does not support any aggregate types (such as arrays, structs, etc) natively.
-You can however (obviously) make your own. In the following section we will cover how \lC\ datatypes are compiled into assembly.
+Assembly does not support any aggregate types (such as arrays, structs, etc) natively. You can however (obviously) make your own.
+In the following section we will cover how \lC\ datatypes are compiled into assembly.

semester3/spca/parts/00_asm/02_dtype-dstruct/03_nested-arrays.tex

@@ -1,7 +1,8 @@
+\newpage
 \subsubsection{Nested / Multidimensional arrays, Struct arrays}
 All of these arrays have similar underlying concepts in the way they are allocated, yet all are a bit different
 
-\content{Common ideas} Each of the array's elements are allocated in contiguous regions of memory, with the elemnts also in contiguous regions of memory.
+\content{Common ideas} Each of the array's elements are allocated in contiguous regions of memory, with the elements also in contiguous regions of memory.
 (Imagine it as lining up all elements on a band, i.e. as going through the array in a nested loop and printing all the elements into a single line.)
 The size of the array is determined by \texttt{n * sizeof(T)}, where \texttt{T} is the type of the elements of the array (or outer array).
 This is what is different for the lot (as well as accessing elements):

semester3/spca/parts/00_asm/03_operations/02_condition-codes.tex

@@ -20,6 +20,9 @@ and \texttt{OF} is set as above, where \texttt{t = a - b}.
 Another instruction that is used is \texttt{testX src2, src1} (X again a size postfix, easier: \texttt{testX b, a}), and acts like computing \texttt{a \& b} and where \texttt{ZF} is set if \texttt{a \& b == 0}
 and \texttt{SF} is set if \texttt{a \& b < 0}.
 
-\content{Zeroing register} We can use a move instruction, but that is less efficient than using \texttt{xorl reg, reg}, where \texttt{reg} is the 32-bit version of the reg we want to zero.
+\content{Zeroing register} We can use a move instruction, but that is less efficient than using \texttt{xorl reg, reg},
+where \texttt{reg} is the 32-bit version of the reg we want to zero. This works because on 32-bit operations,
+the upper 32 bit of the 64 bit register will be zeroed.
 
-\content{Reading condition codes} To read condition codes, we can use the \texttt{setC} instructions, where the \texttt{C} is to be substituted by an element of table \ref{tab:condition-codes}
+\content{Reading condition codes} To read condition codes, we can use the \texttt{setC} instructions,
+where the \texttt{C} is to be substituted by an element of table \ref{tab:condition-codes}

semester3/spca/parts/01_c/01_basics/03_operators.tex

@@ -37,7 +37,7 @@ Very low precedence belongs to boolean operators \verb|&&| and \texttt{||}, as w
 \shade{blue}{Associativity} 
 \begin{itemize}
     \item Left-to-right: $A + B + C \mapsto (A + B) + C$
-    \item Right-to-left: \texttt{A += B += C} $\mapsto$ \texttt{(A += B) += C}
+    \item Right-to-left: \texttt{A += B += C} $\mapsto$ \texttt{A += (B += C)}
 \end{itemize}
 
 As it should be, boolean and, as well as boolean or, support early termination.

semester3/spca/parts/01_c/01_basics/06_integers.tex

@@ -1,4 +1,5 @@
 \subsubsection{Integers in C}
+\label{sec:c-integers}
 As a reminder, integers are encoded as follows in big endian notation, with $x_i$ being the $i$-th bit and $w$ being the number of bits used to represent the number:
 \begin{itemize}[noitemsep]
     \item \bi{Unsigned}: $\displaystyle \sum_{i = 0}^{w - 1} x_i \cdot 2^i$

semester3/spca/parts/01_c/02_preprocessor.tex

@@ -4,13 +4,20 @@ To have \texttt{gcc} stop compiliation after running through \texttt{cpp}, the \
 
 \content{Imports} Imports in \lC\ are handled by the preprocessor, that for each \verb|#include <file1.h>|, the preprocessor simply copies the contents of the file recursively into one file. Note that this can easily lead to errors caused by multiple definitions. Using the \texttt{cpp} directive \verb|#ifndef| can be used to avoid this.
 
-Depending on if we use \verb|#include <file1.h>| or \verb|#include "file1.h"| the preprocessor will search for the file either in the system headers or in the project directory.
+Depending on if we use \verb|#include <file1.h>| or \verb|#include "file1.h"| the preprocessor will search for the file either in the system headers
+(on Linux typically in \texttt{/usr/include/}) or in the project directory.
 Be wary of including files twice, as the preprocessor will recursively include all files (i.e. it will include files from the files we included)
+It is however possible to prevent that from becoming an issue using this (called an \texttt{include guard}):
+
+\inputcodewithfilename{c}{}{code-examples/00_c/01_preprocessor/00_include-guards.h}
+
+The name you pick for the preprocessor macro used in the check, by convention usually has the form \texttt{NAME\_H}.
+It should not start in an underscore (or multiple) and it should not contain more than one consecutive underscore.
 
 The \lC\ preprocessor gives us what are called \texttt{preprocessor macros}, which have the format \verb|#define NAME SUBSTITUTION|.
 \rmvspace
 
-\inputcodewithfilename{c}{}{code-examples/00_c/01_preprocessor/00_macros.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/01_preprocessor/01_macros.c}
 
 To avoid issues with semicolons at the end of preprocessor macros that wrap statements that cannot end in semicolons, we can use a concept called semicolon swallowing.
 For that, we wrap the statements in a \texttt{do \dots\ while(0)} loop, which is removed by the compiler on compile, also taking with it the semicolon.