Markdownify all markdown files

hw2/README.md

@@ -1,6 +1,7 @@
 # hw2
 
 ## Tasks
+
 To fullfill **hw2** you have to solve:
 
 - task1
@@ -13,20 +14,21 @@ Optional are (bonus +1P):
 
 ## Files
 
-You find already files for earch rust task. Please remember to use cargo to create the relevant projects for each task.
-
+You find already files for each rust task. Please remember to use cargo to
+create the relevant projects for each task.
 
 ## ASIDE: `simu1/` dir
 
-In this homework it's not a simulation homework sitting in `simu1/` but some questions to have fun with buggy c-files. As not to interfer with rust code, questions, c-code and your answers should go into `simu1/`.
-
-## Pull-Reuest
+In this homework it's not a simulation homework sitting in `simu1/` but some
+questions to have fun with buggy c-files. As not to interfer with rust code,
+questions, c-code and your answers should go into `simu1/`.
 
-Please merge any accepted reviews into your branch. If you are ready with the homework, all tests run, please create a pull request named **hw2**.
+## Pull-Request
 
-## Gradings
+Please merge any accepted reviews into your branch. If you are ready with the
+homework, all tests run, please create a pull request named **hw2**.
 
-### hw2
+## Gradings of hw2
 
 | Task     | max. Credits | Comment |
 | -------- | ------------ | ------- |

hw2/simu1/QUESTIONS.md

@@ -2,42 +2,71 @@
 
 ## Overview
 
-In this task, you will gain some familiarity with memory allocation. First, you’ll write some buggy programs (fun!). Then, you’ll use some tools to help you find the bugs you inserted. Then, you will realize how awesome these tools are and use them in the future, thus making yourself more happy and productive.
+In this task, you will gain some familiarity with memory allocation. First,
+you’ll write some buggy programs (fun!). Then, you’ll use some tools to help you
+find the bugs you inserted. Then, you will realize how awesome these tools are
+and use them in the future, thus making yourself more happy and productive.
 
-The first tool you’ll use is **gdb**, the debugger. There is a lot to learn about this debugger; here we’ll only scratch the surface. Here you can find a [quick reference gdb][]. Also **ddd** is installed on lab workstations.
+The first tool you’ll use is **gdb**, the debugger. There is a lot to learn
+about this debugger; here we’ll only scratch the surface. Here you can find a
+[quick reference gdb][]. Also **ddd** is installed on lab workstations.
 
-The second tool you’ll use is [valgrind][]. This tool helps find memory leaks and other insidious memory problems in your program.
+The second tool you’ll use is [valgrind][]. This tool helps find memory leaks
+and other insidious memory problems in your program.
 
-Please answer the questions, by giving the result and an explanation, why you got the result.  Write your answers in markdown syntax in the new file `ANSWERS.md`. Also checkin your C-Files and one Makefile for all or your C-Files, so that all binaries are build. Do NOT checkin the binaries!
+Please answer the questions, by giving the result and an explanation, why you
+got the result.  Write your answers in markdown syntax in the new file
+`ANSWERS.md`. Also checkin your C-Files and one Makefile for all or your
+C-Files, so that all binaries are build. Do NOT checkin the binaries!
 
-The installed gcc wraper on you workstations does some optimization to your code examples, which will not show some of the bugs with an "Segmentation fault". We have already disabled this behaviour by setting:
+The installed gcc wrapper on you workstations does some optimization to your code
+examples, which will not show some of the bugs with an "Segmentation fault". We
+have already disabled this behavior by setting:
 
 ```text
 export hardeningDisable=all
 ```
 
-in your labshell bsys environment. So, you don't have to do any further steps to produce unoptimized code with gcc, if you want to.
+in your labshell bsys environment. So, you don't have to do any further steps to
+produce unoptimized code with gcc, if you want to.
 
-If you struggle with your own systems about some strange gcc optimization behaviour, maybe it helps to check for gcc-wrapper variables like these.
+If you struggle with your own systems about some strange gcc optimization
+behavior, maybe it helps to check for gcc-wrapper variables like these.
 
 ## Questions
 
-1. First, write a simple program called `null.c` that creates a pointer to an integer, sets it to `NULL`, and then tries to dereference it. Compile this into an executable called **null**. What happens when you run this program?
-
-2. Next, compile this program with symbol information included (with the `-g` flag). Doing so let’s put more information into the executable, enabling the debugger to access more useful information about variable names and the like. Run the program under the debugger by typing `gdb null` and then, once gdb is running, typing `run`. What does gdb show you?
-
-3. Finally, use the valgrind tool on this program. We’ll use the memcheck tool that is a part of valgrind to analyze what happens. Run
-   this by typing in the following: `valgrind --leak-check=yes ./null`. What happens when you run this? Can you interpret the output from the tool?
-
-4. Write a simple program that allocates memory using `malloc()` but forgets to free it before exiting. What happens when this program runs? Can you use `gdb` to find any problems with it? How about `valgrind` (again with the `--leak-check=yes` flag)?
-
-5. Write aprogram that creates an array of integers of size 100 using `malloc()`; then, set `data[100]` to zero. What happens when you run this program? What happens when you run this program using `valgrind`? Is the program correct?
-
-6. Create a program that allocates an array of integers (as above),frees them, and then tries to print the value of one of the elements of the array. Does the program run? What happens when you use `valgrind` on it?
-
-7. Now pass a funny value to free (e.g., a pointer in the middle of the array you allocated above). What happens? Do you need tools to find this type of problem?
-
-
+1. First, write a simple program called `null.c` that creates a pointer to an
+   integer, sets it to `NULL`, and then tries to dereference it. Compile this
+   into an executable called **null**. What happens when you run this program?
+
+1. Next, compile this program with symbol information included (with the `-g`
+   flag). Doing so let’s put more information into the executable, enabling the
+   debugger to access more useful information about variable names and the like.
+   Run the program under the debugger by typing `gdb null` and then, once gdb is
+   running, typing `run`. What does gdb show you?
+
+1. Finally, use the valgrind tool on this program. We’ll use the memcheck tool
+   that is a part of valgrind to analyze what happens. Run this by typing in the
+   following: `valgrind --leak-check=yes ./null`. What happens when you run
+   this? Can you interpret the output from the tool?
+
+1. Write a simple program that allocates memory using `malloc()` but forgets to
+   free it before exiting. What happens when this program runs? Can you use
+   `gdb` to find any problems with it? How about `valgrind` (again with the
+   `--leak-check=yes` flag)?
+
+1. Write a program that creates an array of integers of size 100 using
+   `malloc()`; then, set `data[100]` to zero. What happens when you run this
+   program? What happens when you run this program using `valgrind`? Is the
+   program correct?
+
+1. Create a program that allocates an array of integers (as above),frees them,
+   and then tries to print the value of one of the elements of the array. Does
+   the program run? What happens when you use `valgrind` on it?
+
+1. Now pass a funny value to free (e.g., a pointer in the middle of the array
+   you allocated above). What happens? Do you need tools to find this type of
+   problem?
 
 [valgrind]: http://valgrind.org/downloads/current.html
 [quick reference gdb]: https://web.stanford.edu/class/cs107/gdb_refcard.pdf

hw2/task1/README.md

@@ -6,24 +6,25 @@ Run the cargo command to prepare your task1/ directory as a library
 
 ## task
 
-Calculate the Hamming difference between two DNA strands by implementing 
-the library function *hamming_distance(s1: &str, s2: &str) -> Result<usize, String>*.
-
-A mutation is simply a mistake that occurs during the creation or
-copying of a nucleic acid, in particular DNA. Because nucleic acids are
-vital to cellular functions, mutations tend to cause a ripple effect
-throughout the cell. Although mutations are technically mistakes, a very
-rare mutation may equip the cell with a beneficial attribute. In fact,
-the macro effects of evolution are attributable by the accumulated
-result of beneficial microscopic mutations over many generations.
-
-The simplest and most common type of nucleic acid mutation is a point
-mutation, which replaces one base with another at a single nucleotide.
-
-By counting the number of differences between two homologous DNA strands
-taken from different genomes with a common ancestor, we get a measure of
-the minimum number of point mutations that could have occurred on the
-evolutionary path between the two strands.
+Calculate the Hamming difference between two DNA strands by implementing the
+library function *hamming_distance(s1: &str, s2: &str) -> Result<usize,
+String>*.
+
+A mutation is simply a mistake that occurs during the creation or copying of a
+nucleic acid, in particular DNA. Because nucleic acids are vital to cellular
+functions, mutations tend to cause a ripple effect throughout the cell. Although
+mutations are technically mistakes, a very rare mutation may equip the cell with
+a beneficial attribute. In fact, the macro effects of evolution are attributable
+by the accumulated result of beneficial microscopic mutations over many
+generations.
+
+The simplest and most common type of nucleic acid mutation is a point mutation,
+which replaces one base with another at a single nucleotide.
+
+By counting the number of differences between two homologous DNA strands taken
+from different genomes with a common ancestor, we get a measure of the minimum
+number of point mutations that could have occurred on the evolutionary path
+between the two strands.
 
 This is called the 'Hamming distance'.
 
@@ -35,7 +36,3 @@ nucleotides are different from their equivalent in the other string.
     ^ ^ ^  ^ ^    ^^
 
 The Hamming distance between these two DNA strands is 7.
-
-
-
-

hw2/task3/README.md

@@ -6,10 +6,13 @@ Run the cargo command to prepare your task3/ directory as a library
 
 ## task
 
-Compute Pascal's triangle up to a given number of rows. Create the new type *PascalsTriangle* and implement the methods *new()* and *rows()*. See the `tests/task3.rs` for more informationen about parameters and returns of the methods.
+Compute Pascal's triangle up to a given number of rows. Create the new type
+*PascalsTriangle* and implement the methods *new()* and *rows()*. See the
+`tests/task3.rs` for more informationen about parameters and returns of the
+methods.
 
-In Pascal's Triangle each number is computed by adding the numbers to
-the right and left of the current position in the previous row.
+In Pascal's Triangle each number is computed by adding the numbers to the right
+and left of the current position in the previous row.
 
 ```plain
     1
@@ -19,7 +22,3 @@ the right and left of the current position in the previous row.
 1 4 6 4 1
 # ... etc
 ```
-
-
-
-