[SPCA] Update code imports

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

@@ -38,6 +38,4 @@ What matters most today are non-technical factors such as existance of code for
 
 \shade{purple}{Example} A \verb|C| function that simply adds $2$ arguments might be compiled (unoptimized) to this:
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{01_sum.s}
-
-
+\inputcodewithfilename{gas}{}{code-examples/01_asm/01_sum.s}

semester3/spca/parts/00_asm/03_operations/00_intro.tex

@@ -6,4 +6,4 @@ Note that \verb|move| instructions \textit{cannot} move data directly from memor
 
 The following instruction formats are commonly used:
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{00_operations.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/00_operations.s}

semester3/spca/parts/00_asm/04_control-flow.tex

@@ -9,23 +9,23 @@ The compiler may translate it very differently depending on the context of the p
 \subsubsection{Conditional statements}
 A function using an \verb|if/else| construct to choose the maximum of $2$ numbers might compile like this:
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{02_max.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/02_max.s}
 
 A function computing the absolute difference $|x-y|$ using an \verb|if/else| construct, might use a conditional \verb|move| instead:
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{03_absdiff.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/03_absdiff.s}
 
 \subsubsection{While Loops}
 
 A recursive factorial function using a \verb|do while| loop may be compiled like this:
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{04_factorial.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/04_factorial.s}
 
 \newpage
 
 The same function, using a \verb|while| loop instead may lead to this:
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{05_factorial.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/05_factorial.s}
 
 \subsubsection{For Loops \& Switch}
 

semester3/spca/parts/00_asm/05_stack.tex

@@ -69,9 +69,9 @@ The stack is commonly used for recursive functions. A recursive factorial functi
 Note how \texttt{\%rbx} is saved on the stack, since \texttt{rbx} is callee-saved by convention. \\
 \texttt{\%eax} is used directly, since it is caller-saved by convention.
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{06_factorial.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/06_factorial.s}
 
 A more complex example, passing addresses as arguments: \\
 This function swaps 2 array elements (using a \texttt{swap} function) and adds the first value to an accumulator.
 
-\inputcodewithfilename{gas}{code-examples/01_asm/}{07_swap_and_sum.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/07_swap_and_sum.s}

semester3/spca/parts/00_asm/06_unorthodox-control-flow.tex

@@ -9,11 +9,11 @@ The \texttt{setjmp( jmp\_buf env } function stores the current stack / environme
 The \texttt{longjmp( jmp\_buf env, int val )} function causes a second return, which returns \texttt{val},
 to the \texttt{setjmp} invocation and jumps back to that place.
 
-\inputcodewithfilename{c}{code-examples/01_asm/}{08_unorthodox-controlflow.c}
+\inputcodewithfilename{c}{}{code-examples/01_asm/08_unorthodox-controlflow.c}
 
 What the above code outputs is: \texttt{second} followed by \texttt{main}.
 
 \newpage
 They are implemented in Assembly as follows. Nothing really surprising for the implementation there.
 The assembly code is from the Musl \lC\ library
-\inputcodewithfilename{gas}{code-examples/01_asm/}{09_setjmp-longjmp.s}
+\inputcodewithfilename{gas}{}{code-examples/01_asm/09_setjmp-longjmp.s}

semester3/spca/parts/00_asm/07_coroutines.tex

@@ -6,7 +6,7 @@ An example is a decompresser that calls a parser when it has finished compressin
 We can implement that either by rewriting the functions into a single function, which often is a bit clumsy.
 A way around this is to use \bi{Continuations}, where the first function saves its state and the context is switched to the other function.
 That function can then load its state and continue where it left off, runs until it finishes its task, then saves its state and the context switches back to the original function.
-\inputcodewithfilename{c}{code-examples/01_asm/}{10_coroutine.h}
-\inputcodewithfilename{c}{code-examples/01_asm/}{10_coroutine.c}
+\inputcodewithfilename{c}{}{code-examples/01_asm/10_coroutine.h}
+\inputcodewithfilename{c}{}{code-examples/01_asm/10_coroutine.c}
 
 As you can see, the \texttt{setjmp.h} functions are the foundation of all concurrent programming.

semester3/spca/parts/01_c/01_basics/00_intro.tex

@@ -1,7 +1,7 @@
 \subsection{Basics}
 \texttt{C} uses a very similar syntax as many other programming languages, like \texttt{Java}, \texttt{JavaScript} and many more\dots
 to be precise, it is \textit{them} that use the \texttt{C} syntax, not the other way around. So:
-\inputcodewithfilename{c}{code-examples/00_c/00_basics/}{00_intro.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/00_basics/00_intro.c}
 
 In \texttt{C} we are referring to the implementation of a function as a \bi{(function) definition} (correspondingly, \textit{variable definition}, if the variable is initialized)
 and to the definition of the function signature (or variables, without initializing them) as the \bi{(function) declaration} (or, correspondingly, \textit{variable declaration}).
@@ -9,4 +9,4 @@ and to the definition of the function signature (or variables, without initializ
 \texttt{C} code is usuallt split into the source files, ending in \texttt{.c} (where the local functions and variables are declared, as well as all function definitions)
 and the header files, ending in \texttt{.h}, usually sharing the filename of the source file, where the external declarations are defined.
 By convention, no definition of functions are in the \texttt{.h} files, and neither variables, but there is nothing preventing you from putting them there.
-\inputcodewithfilename{c}{code-examples/00_c/00_basics/}{01_func.h}
+\inputcodewithfilename{c}{}{code-examples/00_c/00_basics/01_func.h}

semester3/spca/parts/01_c/01_basics/01_control-flow.tex

@@ -9,6 +9,6 @@ And because the labels are (as in Assembly) simply skipped over during execution
 We can also use \texttt{continue} and \texttt{break} statements similarly to \texttt{Java}, they do not however accept labels.
 (Reminder: \texttt{continue} skips the loop body and goes to the next iteration)
 
-\inputcodewithfilename{c}{code-examples/00_c/00_basics/}{01_func.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/00_basics/01_func.c}
 
 

semester3/spca/parts/01_c/01_basics/02_declarations.tex

@@ -3,7 +3,7 @@
 We have already seen a few examples for how \texttt{C} handles declarations.
 In concept they are similar (and scoping works the same) to most other \texttt{C}-like programming languages, including \texttt{Java}.
 
-\inputcodewithfilename{c}{code-examples/00_c/00_basics/}{02_declarations.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/00_basics/02_declarations.c}
 
 \newpage
 A peculiarity of \texttt{C} is that the bit-count is not defined by the language, but rather the hardware it is compiled for.

semester3/spca/parts/01_c/01_basics/04_arrays.tex

@@ -5,4 +5,4 @@
 Unlike some other programming languages, arrays are \bi{not} dynamic length.
 
 The below snippet includes already some pointer arithmetic tricks. The variable \texttt{data} is a pointer to the first element of the array.
-\inputcodewithfilename{c}{code-examples/00_c/00_basics/}{03_arrays.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/00_basics/03_arrays.c}

semester3/spca/parts/01_c/01_basics/05_strings.tex

@@ -3,4 +3,4 @@
 with length of the array $n + 1$ (where $n$ is the number of characters of the string).
 The extra element is the termination character, called the \texttt{null character}, denoted \verb|\0|.
 To determine the actual length of the string (as it may be padded), we can use \verb|strnlen(str, maxlen)| from \texttt{string.h}
-\inputcodewithfilename{c}{code-examples/00_c/00_basics/}{04_strings.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/00_basics/04_strings.c}

semester3/spca/parts/01_c/01_basics/07_pointers.tex

@@ -11,7 +11,7 @@ When a procedure returns, the stack frame is deallocated and any necessary clean
 
 Of note is that if you simply declare a pointer using \texttt{type * p;} you will get different memory addresses every time.
 The (Linux)-Kernel randomizes the address space to prevent some common exploits.
-\inputcodewithfilename{c}{code-examples/00_c/00_basics/}{05_pointers.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/00_basics/05_pointers.c}
 
 \newpage
 \begin{scriptsize}

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

@@ -10,7 +10,7 @@ Be wary of including files twice, as the preprocessor will recursively include a
 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/00_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.

semester3/spca/parts/01_c/03_memory/00_intro.tex

@@ -3,7 +3,7 @@ In comparison to most other languages, \lC\ does not feature automatic memory ma
 This of course has both advantages and disadvantages.
 
 \rmvspace
-\inputcodewithfilename{c}{code-examples/00_c/02_memory/}{00_memory.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/02_memory/00_memory.c}
 \drmvspace
 
 Notably, the argument \texttt{size\_t sz} for \texttt{malloc}, \texttt{calloc} and \texttt{realloc} is an \texttt{unsigned} integer of some size
@@ -15,7 +15,7 @@ you get undefined behaviour.
 \warn{Memory corruption} There are many ways to corrupt memory in \lC. The below code shows off a few of them:
 
 \rmvspace
-\inputcodewithfilename{c}{code-examples/00_c/02_memory/}{01_mem-corruption.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/02_memory/01_mem-corruption.c}
 \drmvspace
 
 \warn{Memory leaks} If we allocate memory, but never free it, we use more and more memory (old memory is inaccessible)

semester3/spca/parts/01_c/04_variadic.tex

@@ -3,4 +3,4 @@
 
 Variadic functions take a variable number of arguments and use the \texttt{...} syntax in \lC.
 A notable example of such a function is \texttt{printf}
-\inputcodewithfilename{c}{code-examples/00_c/03_others/}{00_variadic.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/03_others/00_variadic.c}

semester3/spca/parts/01_c/05_vulnerabilities.tex

@@ -23,7 +23,7 @@ There are 2 ways to do this:
 
 For example, consider this code:
 
-\inputcodewithfilename{c}{code-examples/00_c/05_vulnerabilities/}{01_buffer_overflow_echo.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/05_vulnerabilities/01_buffer_overflow_echo.c}
 
 This is a problem, since \texttt{echo} may be compiled to something similar to this:
 

semester3/spca/parts/02_toolchain/02_linking.tex

@@ -78,6 +78,6 @@ Using just the Linker, there are only 2 inconvenient ways to package libraries:
 
 During runtime, shared libraries can be loaded using \texttt{dlopen}:
 
-\inputcodewithfilename{c}{code-examples/00_c/04_toolchain/}{01_dynamic_linking.c}
+\inputcodewithfilename{c}{}{code-examples/00_c/04_toolchain/01_dynamic_linking.c}
 
 \newpage

semester3/spca/parts/03_hw/07_dev.tex

@@ -26,7 +26,7 @@ The specific way this interaction works is device-specific.
 
 \content{Example} A very simple device driver in \texttt{C} may look like this:
 
-\inputcodewithfilename{c}{code-examples/03_hw/}{00_driver.c}
+\inputcodewithfilename{c}{}{code-examples/03_hw/00_driver.c}
 
 Of course, a proper driver would also include error handling, initialization and wouldn't spin to wait. To avoid waiting, interrupts are usually used.