How Does getline Work in C? | Size, Buffer, And Pitfalls

getline looks odd the first time you see it. A pointer to a pointer. A pointer to a size. A signed return value. That shape is not there to be clever. It is there so the function can grow your buffer when the next line is longer than you guessed.

Once that clicks, the rest falls into place. getline reads from a FILE * stream until it sees a newline or hits end-of-file. It writes the bytes into a buffer, adds a trailing '\0', and tells you how many bytes it stored. That makes it handy for terminal input, config files, log files, CSV rows, and any other text where line length can swing from tiny to huge.

How Does getline Work in C? Step By Step

The function reads one full line at a time. If your current buffer is big enough, it reuses it. If not, it grows the buffer and updates your pointer. You do not need to guess a line length up front, and you do not need to stitch together partial reads by hand.

That is why the call shape looks like this:

ssize_t getline(char **lineptr, size_t *n, FILE *stream);

The Three Arguments

Each argument has one job, and each one solves a real problem.

• lineptr points to your buffer pointer. The function may replace that pointer after a new allocation or reallocation.
• n points to the current buffer capacity. The function updates it when the buffer grows.
• stream is the input source, such as stdin or a file opened with fopen.

A common starting pattern is char *line = NULL; and size_t cap = 0;. In that setup, getline allocates the first buffer for you. After that, it keeps reusing or growing the same buffer across calls.

What The Return Value Means

The return value is where many newcomers trip. On success, you get the number of bytes read. That count does not include the terminating null byte. It does include the newline if a newline was read before end-of-file.

• If the input line is cat\n, the return value is 4.
• If the file ends with cat and no trailing newline, the return value is 3.
• If no bytes are read because the stream is already at end-of-file, the function returns -1.

That signed return value matters. It lets the function report a real byte count on success and still use -1 for end-of-file or a read failure.

What getline Keeps Track Of During A Read

There are three moving parts during a call: the buffer address, the buffer capacity, and the number of bytes read. If you mix those up, your program may still compile and run, yet it will start doing odd things the moment the input gets longer.

This table pins each part down in plain terms.

Part	What getline Does	What You Need To Know
lineptr	May start as NULL and later point to allocated memory	Always use the updated pointer after the call
n	Stores buffer capacity, not line length	It may grow after a long line
stream	Supplies bytes from stdin, a file, or another stream	The function works on any valid FILE *
Newline	Keeps the newline when one is read	Trim it only if your program does not want it
Terminating '\0'	Adds one after the data	You can treat the buffer as a C string
Return value	Reports bytes read, excluding the trailing null byte	Use it for length checks, not n
End-of-file	Returns -1 when no bytes are read at end-of-file	Use feof() or ferror() if you need the exact reason
Reallocation	May move the buffer to a new address	Free only the current pointer when you are done

A Small Program That Makes It Click

Here is a tight sample. It reads every line from standard input and prints the byte count beside the text. The same pattern works for files too; you would just swap stdin for a file stream.

#include 
#include 

int main(void) {
    char *line = NULL;
    size_t cap = 0;
    ssize_t len;

    while ((len = getline(&line, ∩, stdin)) != -1) {
        printf("Read %zd bytes: %s", len, line);
    }

    free(line);
    return 0;
}

There are two details worth slowing down for. One, the buffer is freed once, after the loop. Two, the loop keeps passing the same pointer and the same capacity back into getline. That lets the function reuse memory instead of starting from scratch on each pass.

If your compiler says getline is undeclared, the issue is usually portability, not your syntax. The function is part of POSIX, not ISO C. The POSIX getline specification spells out the official behavior, while the GNU C Library line-input docs walk through the allocation pattern in everyday terms.

getline Vs fgets In Real Input Work

fgets is still fine when the maximum line length is fixed and small. If you know each line fits in 64 bytes, a fixed buffer is plain and cheap. The trouble starts when line length is unknown. Then a fixed buffer can cut a line in half, leave the rest in the stream, and make your next read start in the middle of old data.

That is where getline earns its keep. It keeps reading until the full line is collected or end-of-file arrives. You do not need retry loops or hand-rolled growth logic. The risk with fixed-width input is not theoretical either. The CERT note on fgets truncation shows how easy it is to keep only part of a line and then continue as if the read was complete.

That does not make getline the right pick for every job. It is just a better match when input size is not stable.

Slip	What Goes Wrong	Better Habit
Treating n as line length	You read buffer capacity as if it were used bytes	Use the return value for the actual line length
Forgetting to free the buffer	Heap memory leaks after repeated reads	Call free(line) once at the end
Blindly trimming the last byte	You may chop valid data when no newline was stored	Trim only when len > 0 and the last byte is '\n'
Using %d for the length	Printed output can be wrong on some builds	Print ssize_t with %zd
Freeing inside the loop too early	The next call may reuse a dead pointer	Keep one live buffer through the loop

Mistakes That Bite New C Programmers

Most getline bugs are not wild. They come from one small mix-up that spreads across the rest of the code.

• Confusing capacity with content length. The variable behind n tells you how much room the buffer has. It does not tell you how many bytes were read this time.
• Assuming the newline is gone.getline keeps it when it was present in the input. That is handy when you want to preserve exact file content, yet it can break string comparisons if you forget it is there.
• Throwing away the signed length. If you cast the return value to an unsigned type too early, the -1 end marker can turn into a huge positive number.
• Calling strlen when raw length already exists. You already have the byte count from the return value. Use it. It is cheaper and safer.
• Freeing the wrong pointer. Reallocation may move the buffer. Free the pointer you have after the last call, not an older saved address.

There is one more wrinkle worth knowing. The return value can be more trustworthy than strlen if your input may contain embedded null bytes. That is not common in plain text files, yet it shows why the function reports a byte count instead of asking you to recompute one later.

When getline Fits Best

getline shines when you need one clean rule for line input and do not want to play guessing games with buffer size. It is a strong fit when you are:

• reading text files with uneven line lengths,
• accepting user input where line length is open-ended,
• looping through config files or logs,
• parsing line by line before splitting fields.

If strict ISO C portability is your top concern, you may need a fallback on toolchains that do not provide POSIX APIs. In that setting, fgets plus manual buffer growth is still a workable route. On POSIX systems, getline is usually the cleaner choice.

A Clean Mental Model

Think of getline as a line reader that manages buffer growth for you. You hand it a pointer it may replace, a capacity it may change, and a stream to read from. It hands back a full line, newline included when present, plus a length you can trust. Once you see it that way, the double pointer stops looking strange and starts feeling tidy.