Exam 01 Piscine 42 Exclusive
42 School Piscine Exam 01 is a high-stakes, 4-hour technical challenge that serves as the second major test in the intensive C programming bootcamp. While Exam 00 covers the basics of the shell and simple functions, Exam 01 adds command-line arguments ( and more complex logic. The Story: A Friday in the Cluster 1. The Pre-Exam Tension
Friday at 42 is "Exam Day." The energy in the cluster shifts from collaborative chaos to a heavy, nervous quiet. At exactly 2:00 PM, all students are logged out, and the machines reboot into a specialized, restricted Linux environment. You have exactly 10 minutes to log in to the
using the generic "exam" credentials; failure to do so results in an immediate 0. 2. Entering the Exam Shell Once you launch the
command, the real game begins. The interface is text-only. You must log in again with your personal intranet ID and password. The environment is designed to be isolated—no internet, no notes, and no peer help. 3. Solving Level by Level
The exam is structured like a video game: you must pass one exercise to unlock the next.
Often a basic output task, such as printing the last command-line argument using only the Level 1-2:
Tasks move into string manipulation, such as writing your own version of (string copy) or (string comparison).
If you fail an exercise, you might be given a different task at the same difficulty level, but it will be worth fewer points. 4. The Dreaded
To submit your work, you move your C file into the designated folder, commit it, and type in the shell. Then, you wait. The Moulinette
(the automated grading system) tests your code against edge cases. If there is even one extra space or a minor logic flaw, it returns a "FAILURE" message, and your score for that attempt remains 0. 5. The Aftermath
At 6:00 PM, the session ends abruptly. For many, the first exam is a lesson in humility, with some students scoring as low as 30 due to stress or minor syntax errors. However, at 42, failure is part of the curriculum—the school looks for resilience and growth over the four weeks rather than perfect scores on day one. Summary of Key Exam 01 Topics Focus Area Basic Logic Loops, conditionals, and character manipulation Command Line to process inputs Iterating through arrays and handling the null-terminator ( System Calls Outputting data exclusively using the Are you preparing for a specific exercise like for your next exam? 42-piscine/README.md at main - GitHub exam 01 piscine 42 exclusive
The Exam 01 in the 42 Piscine is your first major "sink or swim" moment. While "Exam 00" (if your campus holds it) is often a trial run to test the environment, Exam 01 is where the real grading begins, typically focusing on C language fundamentals and basic Shell scripting. Core Topics to Master
To pass Exam 01, you must be comfortable with the following concepts, as questions are randomly drawn from these pools:
Shell Scripting (Shell 01 level): Expect tasks like print_groups, find_sh, and count_files.
Basic C Syntax: Handling argc and argv (command-line arguments) is a common requirement for this exam level.
Functions & Logic: You will likely need to write functions like ft_putstr, ft_strlen, or ft_swap.
Loops and Conditionals: Heavily tested through simple algorithmic problems (e.g., printing numbers in a specific order or basic string manipulation). The "ExamShell" Workflow
The exam doesn't use the standard Git submission you use for daily projects. Instead, it uses a dedicated ExamShell environment.
Login: You will log into a restricted session. RTFM (Read The F***ing Manual) or ask peers beforehand on how to access the exam machine at your specific campus.
Rendu Directory: You must save your files in the rendu/ directory provided by the system.
The grademe Command: Once you think your code is perfect, you type grademe in the terminal. 42 School Piscine Exam 01 is a high-stakes,
Immediate Feedback: The "Moulinette" (grading bot) will check your code instantly. If you fail, you often have to wait a mandatory "cooling off" period (e.g., 5-15 minutes) before trying the next exercise. Critical "Exclusive" Tips
Exam 01 — Piscine 42 Exclusive
Overview
- Exam 01 is an introductory, intensive assessment typical of the 42 (École 42) piscine format: focused on hands-on coding, problem solving, and peer evaluation over a short, high-pressure window.
- Goal: verify foundational skills (algorithms, debugging, code style, Unix tooling, collaboration) and readiness for subsequent modules.
Key topics likely covered
- C fundamentals: pointers, memory allocation (malloc/free), arrays, strings, structs
- Control flow: loops, conditionals, recursion
- Basic algorithms: sorting, searching, string manipulation, basic graph/recurrence reasoning
- Unix tools: gcc, make, shell commands, piping, redirection, basic bash scripting
- Debugging: gdb, valgrind (memory leaks), reading segmentation faults
- Code organization: header files, modular compilation, Makefiles
- Time/space considerations: simple complexity reasoning, avoiding O(n^2) where feasible
- Collaboration & workflow: using peer review, following project specs, writing meaningful commits
Practical tips — before the exam
- Environment prep
- Have a minimal, working toolchain: gcc, make, gdb, valgrind, vim/VSCode, shell familiarity.
- Configure a simple Makefile template you can adapt quickly.
- Fundamental drills (daily 30–60 min)
- Implement and explain: strlen, strcpy, strcmp, atoi/itoa, strdup, memcpy.
- Practice pointer exercises: pointer arithmetic, arrays of pointers, function pointers.
- Solve a few basic sorting implementations (bubble, insertion, quicksort).
- Debugging routine
- Intentionally introduce small errors in short programs and practice interpreting segfaults and valgrind output.
- Learn common symptoms: null deref, buffer overflow, double free, uninitialized reads.
- Time management
- Timebox tasks: read spec 5–10 min, plan 10–15 min (inputs/outputs, edge cases), implement, then test and debug.
- Prioritize getting a correct, simple solution before optimizing.
- Read specs strictly
- Follow exact output formatting, return codes, and allowed functions. Failing format checks typically costs points.
- Versioning & backups
- Commit small, incremental changes with clear messages so you can revert easily.
- Keep local copies of working checkpoints before risky refactors.
- Peer feedback
- Practice explaining your code and receiving critique succinctly; verbalizing logic often exposes flaws.
- Stress & endurance
- Simulate exam pace by doing timed mini-projects; build mental stamina.
Practical tips — during the exam
- First 5–10 minutes: read all instructions, examples, and forbidden functions; note edge cases.
- Minimal viable product (MVP)
- Implement the simplest correct behavior first (happy-path), even if it doesn’t handle all edge cases.
- Incremental testing
- Compile after small changes; write quick test cases to validate assumptions.
- Defensive coding
- Check NULLs, validate sizes, avoid undefined behavior.
- Use tools early
- Run valgrind and gdb at the first sign of strange behavior rather than hunting blindly.
- Keep code readable
- Use clear variable names and short helper functions; examiners read code—clarity helps.
- If stuck, switch
- Move to another task or problem, then return with fresh eyes.
- Submit early, iterate
- If there’s a submission checkpoint, submit a working minimal solution first, then improve.
Common pitfalls and how to avoid them
- Off-by-one errors: test empty, one-element, and boundary-size cases.
- Memory leaks/crashes: always pair malloc with free and test with valgrind.
- Undefined behavior from uninitialized vars: initialize variables upon declaration.
- Misreading spec: underline required I/O formats and examples.
- Overengineering: prefer straightforward, maintainable code under time pressure.
Checklist to run before final submission
- Code compiles without warnings (use -Wall -Wextra -Werror if allowed).
- Program matches output formatting exactly (whitespace, newlines).
- No memory leaks or invalid accesses (valgrind clean).
- Edge cases handled (empty inputs, max/min sizes).
- Makefile builds and cleans properly.
- Commit history present if required.
Short study plan (7 days — focused) Day 1: C basics — pointers, arrays, strings; implement string helpers. Day 2: Memory — malloc/free, struct usage, simple linked list. Day 3: Algorithms — implement sort/search, practice complexity reasoning. Day 4: Unix & tooling — gcc flags, Makefile, gdb basics, valgrind runs. Day 5: Timed mini-project — build small program under strict time limit. Day 6: Peer review practice — swap code, review and explain. Day 7: Full mock exam — simulate exam conditions, then fix issues found.
Quick reference commands
- Compile: gcc -Wall -Wextra -Werror -std=c11 -o prog prog.c
- Run: ./prog < input.txt
- Valgrind: valgrind --leak-check=full ./prog
- Debug: gdb --args ./prog arg1 arg2
Concluding note
- Focus on correctness first, then safety (memory) and style; practice under timed conditions; use tools early to catch errors. Good luck.
📌 Final Verdict
Exam 01 is fair but unforgiving. It doesn't test genius – it tests:
- Can you follow strict rules (Norminette)?
- Can you write loops without copying from internet?
- Can you handle edge cases?
If you practiced the 9 shell exercises and 9 C exercises above (total 18), you will pass. No surprises.
Pro tip from 42 alumni: The night before Exam 01, redo
ft_putnbrfrom memory 5 times. Then sleep. That single function is the difference between passing and retake.
Good luck. You will bleed, but you will learn. 🔥
4.2 Without XOR operator (if explicitly required)
unsigned char ft_exclusive(unsigned char a, unsigned char b) unsigned char result = 0; int i = 0;while (i < 8) unsigned char bit_a = (a >> i) & 1; unsigned char bit_b = (b >> i) & 1; unsigned char xor_bit = (bit_a ^ bit_b); // still uses ^, replace with: // xor_bit = (bit_a return (result);
To completely avoid ^, replace the line:
unsigned char xor_bit = (bit_a | bit_b) & ~(bit_a & bit_b);
Phase 4 – The Boss: ft_putnbr
If you get this, stop everything. Write it on paper first:
- Handle negative: print '-', then
n = -n - Handle
-2147483648as special case - Recursion or loop? Use recursion: if
n > 9, callft_putnbr(n / 10), then printn % 10 + '0'
11. ft_print_numbers
Task: Print numbers 0 to 9.
- Output:
0123456789\n