Libft - The Foundation of Low-Level

In C programming, mastering the fundamentals is the gateway to efficiency, performance, and deep system-level expertise. Libft (Library forty-two), the very first core project in 42’s curriculum, challenges students to recreate essential functions of the C Standard Library from ground up.

Excerpt from the project instructions - You need to re-implement several libc functions using only C89, following their original prototypes and behavior as defined in the man pages. The only difference is their names—they must start with ft_ (e.g., strlen → ft_strlen).

The project was divided into two mandatory parts and a bonus section. Initially, I found the first part quite easy and quick to complete, as most of the functions were straightforward, except a few. However, the second part was much more challenging—some functions were difficult to grasp, and even their man page explanations didn’t make much sense to me.

To understand them better, I searched on Google, read discussions on Stack Overflow and GeeksforGeeks, and consulted ChatGPT. I found that having the concepts broken down step by step made them much easier to understand.

Functions in Part 1

ft_isalpha ft_isdigit ft_isalnum ft_isascii ft_isprint ft_strlen ft_memset ft_bzero ft_memcpy ft_memmove ft_strlcpy ft_strlcat ft_toupper ft_tolower ft_strchr ft_strrchr ft_strncmp ft_memchr ft_memcmp ft_strnstr ft_atoi ft_calloc ft_strdup

As I mentioned before, just by reading their names, you can tell that the functions in part 1 are quite simple. Nevertheless, I still learned some subtle but important details about coding—understanding why one approach is preferred over another, even when the results seem similar but aren’t exactly the same. I particularly found strnstr and atoi a bit more challenging; it took me some time to fully grasp their functionality.

Functions in Part 2

ft_substr ft_strjoin ft_strtrim ft_split ft_itoa ft_strmapi ft_striteri ft_putchar_fd ft_putstr_fd ft_putendl_fd ft_putnbr_fd

My opinion on this project "It’s easy" flipped a full 180 degrees the moment I started working on split. I realized that looking at code is as easy as it is difficult to write it. On my first attempt, I couldn’t manage to write anything useful. So, I took a break and started fresh the next day. Even overnight, I kept thinking about the logic and how it should work. Going through the code line by line, breaking it down, and truly understanding it made me realize how something seemingly simple can quickly become complex—perhaps because I’m still new to coding, something simple isn’t so simple for me. It took me three days, on and off, to fully grasp the concept and write it from scratch by myself. Another interesting challenge was memory leaks, which I first encountered while working on itoa. Using malloc added an extra layer of responsibility—one that must be taken care of.

After completing the second part, it was time for the bonus, but I decided to leave it for later as it felt overwhelming at that moment. It was about manipulating lists—and little did I know, the more projects I unlocked, the more unavoidable lists became. Skipping it wasn’t the smartest move, but at that time, I had to focus on submission as well.

Figure 1.1: Directory displaying all project files

Now, it was time for submission, and for that, I had to create a Makefile to compile the library automatically. Learning how to write one took me another day, but by the end, I understood it well enough to compile both small and moderately big projects with custom requirements. I learned how to write rules and how they are executed, how dependencies work, and the implicit rule concept of Makefiles. Make itself is a complex program—learning everything in one go is neither possible nor recommended. But mastering the basics definitely makes a programmer’s life a lot less tiring. In the process, I also learned why the ar command is used along with the rcs flags to compile the library.

Now, the final step—testing everything before the final push into the submission repository. I had already tested each function individually during the coding process, but only for basic functionality. This was the stage where I learned about sanitization and error handling. It's all good when the input's perfect, but what if it's not? I now had to consider all possible inputs and handle them accordingly—and thinking of every edge case wasn’t as simple as I initially thought.

Figure 1.2: Output from the Tester

At first, I was testing everything manually, but after discussing with some friends, I found out that there were testers for this project, written by senior students. A sigh of relief! Thanks to those who created them, it saved a lot of time and effort. This experience also made me think—after gaining enough programming knowledge, I’d like to create my own tester someday.

One important thing I learned from this project is that every minute detail is just as important as the major ones. For anyone looking to learn the basics of C programming, improve problem-solving skills, or break into systems programming, Libft is the perfect starting point.