1. First-attempt question are 9 points (unlike in previous exams, where they were 16 or 20). Second-attempt questions are 4 points. Third-attempt questions are 0 points and only serve for you to go to the next level. So expect to code up at least 11 questions (well, unless you suffer a premature exit)
2. Don’t forget to git add, git commit, git push before grademe. Don’t push any test files (e.g., your main.c if all they are asking for is a function​)
3. Don’t type the name of directories, submission files, and function prototypes; instead, copy-and-paste​ the names from the instructions to avoid typos (e.g, so you won’t type “world” instead of “word”)
4. Practice writing code now for known exam questions https://github.com/gcamerli/examshell https://alexkassil.github.io/piscine/2017/07/21/Piscine-Exam-Final.html
5. Sleep early tonight. Maybe get some melatonin and some earplugs.
6. Don’t set off the fire alarms the night before
   

1. When you start a terminal window, first thing you do: alias gcc='gcc -g​ -Wall -Wextra -Werror' a. You could try to have it remembered for every shell, but it’s risky as I didn’t get that to work (your shell is sh, not zsh nor bash). echo "alias gcc='gcc -g​ -Wall -Wextra -Werror'" >> ~/.profile
2. Before the exam, learn to use the lldb debugger a. 2 use cases: i. To quickly find segmentation faults or bus errors ii. To set breakpoints and find out what the values of your variables are b. To use lldb: i. compile all files with -g (already did if you used the above gcc alias) ii. run: lldb NAME_OF_YOUR_PROGRAM iii. inside lldb, run: run ARGUMENTS_IF_ANY and if your program segfaults, it will list the lines of your source code where it happens iv. to set breakpoint before run: b LINE_NUMBER
3. then run until the execution stops
4. then you can do p VAR_NAME to see its value
5. Use n, s, to c to continue execution (n steps over, s steps into, and c continues execution until next breakpoint or error v. to pass a file to standard input, inside lldb: process launch -i FILENAME vi. You can also run gui to launch the debugger GUI to more easily set breakpoints and see local variables and stack traces.
6. To test the output of your program against a reference, you can use the <(cmd) operation: $ diff <(cmd1) <(cmd2) will display the difference (if any) between the standard output of cmd1 vs the output of cmd2. For example, to test your do-op program you could do this: $ diff <(./do-op 3 + 5) <(expr 3 + 5)
7. Looping repetitive tasks can keep you focused on writing code. For example, open a separate terminal window and do: a. $ while sleep 1; do clear && gcc -g -Wall -Wextra -Werror main.c program.c [..etc..] && ./a.out [arguments]; done
8. For every question, first thing you do is create a .gitignore file in your submission directory that contains:

!NAME_OF_FILE_TO_SUBMIT.c This will prevent you from accidentally submitting any extra files that you’re not supposed to.

1. Remember to test with the minimum and maximum integers. To find them: a. vim /usr/include/stdint.h

• or - b. Run bc i. Min: Type -2^31, which will give you -2147483648. ii. Max: Type 2^31 - 1, which will give you 2147483647 c. man integer (find that number, you’ll see it)
  

2. Decide whether it makes sense to write your tests in a main or in a shell script. Shell scripts are often faster to generate lots of tests with different arguments, but you need to set up your main to accept arguments; so memorize this example setup main.c: #include <stdlib.h> #include <stdio.h> int main(int argc, char **argv) { int result; result = my_func(argv[1], atoi(argv[2])); printf("%d\n", result); }

WARNING: this is a main.c only for testing when they ask for a function​; if they ask you for a program​, then you can’t use atoi or printf -- you have to write your own ft_atoi, ft_putstr, ft_putnbr, etc. And here is an example test shell script runtests.sh: #!/bin/sh ./a.out ./a.out -1 ./a.out 0 ./a.out 1 2 ./a.out " garbage" " 12garbage "

3. If you use malloc, remember to #include <stdlib.h> in the .c file you submit (not in some separate header file that you are not submitting).

4. When you are create an array of arrays (e.g., an array of strings), read the instructions carefully to see if you need to NULL-terminate (set to 0) this array of arrays (of course, the char arrays themselves should also be NUL-terminated)

5. Consider doing Test-Driven Development: write your test cases (with all the edge cases) before you write your code. That way, you won’t be lazy and just write only a few tests cases before submitting your code.

● man ascii ○ scroll to the bottom to find the decimal numbers..
● man isspace ○ Has whitespace characters that need to be skipped if you implement atoi
● man 2 write
● man 2 read
● man integer ○ To see the maximum and minimum integers

● May use more than one piece of paper.
● May use restroom.
● Dry food examples: granola bars, protein bars.