Methods
42 (II): get_next_line, reading files line by line
Static buffers and memory between calls: the project that teaches you what's going on
2 min read
As kids, we've all read files line by line in some language: readline, fgets, whatever. At 42 this doesn't exist: you have read (the most basic call to read data), a file descriptor (the number that identifies an open file) and your ability to organize memory. After assembling the toolbox in 42 (I): libft, it was time for the second essential: get_next_line, a function that, called in a loop, returns one line at a time from any file.
The problem
The difficulty isn't reading: it's returning exactly up to the newline when read works with chunks. The function reads from the file in fixed-size chunks (BUFFER_SIZE, which can change between tests), and a line might be shorter than the chunk, much longer, or end without a newline at the end of the file. In addition, between calls you have to remember where you left off. And in the bonus part, the extra and optional one, doing this with multiple open files at the same time without mixing them up. All without any memory leak (memory requested and never returned), because every byte counts.
How I approached it
The central piece is a static buffer: a memory region that survives between calls and stores what you've read and haven't consumed yet. Each call, the function checks if there's already a complete line in the buffer; if not, it reads from the file again and appends it; when the newline appears, it cuts off the line, returns it, and leaves the rest in the buffer for the next call.
It sounds simple, but the hidden detail is the variety of cases: empty files, multiple empty lines in a row, the last line without a newline... I made my own test files — one with short lines, one with a kilometer-long line, one empty — and I tested with BUFFER_SIZE from 1 up to huge values, to verify that the behavior was always the same. I also saved an annotated version of the code to study it calmly: in the repository, 42_get_next_line, the mandatory version, the bonus, and various test mains live side by side.
What I got out of it
That project changed my relationship with read: before it was "the call that reads files"; now I know it reads bytes in chunks, that it can return fewer than you ask for, and that the shell (the command interpreter of the terminal), scripts, and everything else live on top of this mechanic. It also made clear to me the value of a well-understood static variable and, above all, the habit of testing the cases that don't appear in the subject (the school's statement). There's a specific satisfaction in seeing the same code correctly read a file with one-character lines and another with a million characters. The third step of the series was writing my own printf: 42 (III): ft_printf.