This project has been created as part of the 42 curriculum by acamelo.

Piscine C 04 🚀

---

Description

This project belongs to the C programming block of the Piscine at 42 Madrid. The central objective of the C 04 module is to master foundational manipulation of basic data types, output streams using low-level system calls, and the intricate parsing mechanics behind string-to-integer conversions.

Through these exercises (ex00 to ex03), the module challenges the student to correctly evaluate memory addresses, safely buffer character outputs directly to the standard output descriptor, and build a highly customized, resilient numeric parser (ft_atoi). This parser must process erratic streams of layout whitespaces and consecutive mathematical operators without risking numerical overflow or undefined behaviors.

All solutions strictly comply with The Norm rules, forcing the code to be elegant, compact, and optimized within strict architectural constraints.

---

Instructions

Compilation Requirements and Environment

The code is written to be entirely native to Unix/Linux environments. Compilation is performed using the standard gcc (or clang) engine alongside the mandatory strict flags of the school to treat any implicit warning as a blocking compilation error:

-Wall -Wextra -Werror

Execution Process and Unit Testing

Since 42 Piscine repositories contain purely isolated logic functions without structural entry points, you must introduce a main.c file to manually execute and test your functions.

To compile and verify the expected outputs of any module locally:

1. Navigate into the target exercise folder:

cd ex03/

2. Add a local test file (main.c): Ensure it holds diverse string arrays (empty streams, multiple signs, spaces) to thoroughly cross-examine your code's outputs.
3. Compile the functional binary:

gcc -Wall -Wextra -Werror ft_atoi.c main.c -o test_executable

4. Run the testing engine:

./test_executable

---

Algorithm Explanation and Justification

The software architecture applied in this module shifts toward linear sequential stream parsing and basic asymmetric numerical representation. The breakdown and technical justification for each logic choice are detailed below:

1. Pointer Traversal Tracking (ft_strlen)

• Mechanics: The algorithm utilizes a raw pointer traversal counter. An index jumps through the memory block byte-by-byte, checking if the memory address evaluates to the string sentinel (\0).
• Justification: By keeping a single accumulator variable, it remains highly efficient with an operational complexity of $O(N)$ in time and an absolute structural requirement of $O(1)$ in auxiliary space.

2. Low-Level Stream Flushing (ft_putstr)

• Mechanics: This algorithm scans the input memory address sequentially and wraps the atomic Unix system call write(). It isolates each character memory cell &str[a] and flushes exactly 1 byte at a time to the standard output file descriptor (1).
• Justification: This structure completely bypasses high-level buffering mechanisms, allowing direct low-level kernel pipeline transmission without incurring stack allocation overhead.

3. Comprehensive State-Machine String Parsing (ft_atoi)

• Mechanics: The algorithm converts a string into a signed integer. To achieve this within a single control stream, it is broken down into three consecutive sequential states:

1. Whitespace Skipping: It loops through ASCII layout spaces and control characters (ASCII values 9 to 13, and 32).
2. Sign State Inversion: It reads an indefinite consecutive stream of + and - characters. If a minus sign is met, it updates a multiplier tracking state (sign = sign * -1), elegantly resolving odd and even mathematical polarity blocks.
3. Base-10 Numerical Accumulation: As long as the stream reads clean digital values ('0' to '9'), it accumulates the values using standard arithmetic positioning (a = (a * 10) + (str[i] - '0')).

• Justification: This state separation is highly optimized for performance. It acts like a finite state machine that evaluates the stream in a single linear pass ($O(N)$ time complexity). By stopping immediately at the first invalid non-numeric byte, it matches the exact behavior of standard parsers without needing dynamic validation matrices or heavy secondary allocation buffers.

---

Resources

Classic References and Documentation

• Linux Programmer's Manual - STRLEN(3): Specifications on string measurements.
• Linux Programmer's Manual - WRITE(2): Direct kernel system call control for file descriptors.
• Linux Programmer's Manual - ATOI(3): Standard behaviors, syntax controls, and structural constraints for numeric parsing.

Artificial Intelligence Deployment Statement

In compliance with the academic integrity guidelines of the 42 network, the deployment of Artificial Intelligence tools during this module was exclusively restricted to:

• Barycentric Edge-Case Generation: AI helped design extreme test vectors for the ft_atoi function. This included inputs with massive sequences of active signs (---+---++123), leading spaces, strings missing numeric bodies entirely, and null pointer safeguards.
• Syntax and Norm Alignment: AI checked loop architectures against strict 42 Norm requirements to prevent conditional scope mistakes.
• Documentation Formatting: AI assisted in organizing the Markdown structure of this README.md to ensure concise and precise terminology for data types and state machine architectures.