Thread: How does buffered output work exactly?

You would think that programs execute gradually, line by line. However, with printf (and perhaps other functions available), it isn't so simple.

For example, i have this simple program for testing this:

Code:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main ()
{
    printf("\n Hello");
    printf("\n This is a test.");
    sleep (1);
    return 0;
}

The solution to this issue is here:

c - Why is the line following printf(), a call to sleep(), executed before anything is printed? - Stack Overflow

If fflush isn't in there, then what happens is that "Hello" prints to the screen, sleep is called, then the program prints "This is a test" before control is returned to me through the terminal.

What I'm still curious is how exactly the printf's buffered output works to make it execute like that. I completely understand how to use fflush to make everything execute properly (putting it directly after the printf lines flushes all the text to stdout), but I am very curious how the stack is ordered in this miniature program to make it work like this in sudo code:

Code:

print hello
sleep one second
print this is a test

FILE type is an opaque type which keeps a buffer inside, used to streaming data. Some streams are "line buffered", like stdout, which means they flush the contents of this buffer if it is full OR if a '\n' is found. When you do:

Code:

printf( "\nHello" );

printf() will add every single char to the stdout stream, but when a '\n' is writen, the entire buffer is flushed.

Code:

.+---------- flushes the buffer and writes '\n'.
 |   +------ just add those to the buffer, not flushing.
 V VVVVV
"\nHello"

The "Hello" part is added to the buffer inside stdout, and is kept there.

The next printf: printf( " world\n" );, adds " world" to the buffer, but when '\n' is found, the entire buffer is flushed and '\n' is writen.

That's why is advisable to call fflush() when there's no '\n' at the end of the string if you want it immediatly printed (or writen to file).

Notice that stdout is line buffered, but stderr isn't. This is controlled by setvbuf() function:

Code:

int setvbuf( FILE *stream, char *buf, int mode, size_t size );

With this function you can setup your own buffer and tell if the stream is line buffered or not. Like that:

Code:

static char buffer[32768]; // 32 KiB

setvbuf( stdout, buffer, _IOLBF, sizeof buffer );

Now we have stdout with a big buffer and it is line buffered (_IOLBF) -- The default buffer size is BUFSIZ (in my system, 8 KiB). You can change only the buffering scheme with:

Code:

// After that, stdout isn't line buffered anymore and the original buffer is kept.
setvbuf( stdout, NULL, _IONBF, 0 );

There's a _IOFBF too, which means the buffer is flushed only when it is full.

PS: fopen() always create an object to a line buffered stream if "t" is informed in the mode or a fully buffered if "b".

PS2: This buffering scheme is useful to keep functions dealing with streams fast. write(), which deals with file descriptors, isn't buffered and can block the thread until all data is writen.

Originally Posted by flp1969

PS: fopen() always create an object to a line buffered stream if "t" is informed in the mode or a fully buffered if "b".

Perhaps in some oddball systems. Standard C says any string besides "r"/"w"/"a"/"r+"/"w+"/"a+", optionally with a "b" flag (and in C11 or later, optionally with an "x" flag), gives undefined behavior. The default (per the C standards) is to open a file in "text" mode anyway, so the "t" flag (meaning "text") seems pretty useless, IMO.

Yep... my mistake... using 't' is wrong!

One thing, thou: C11+ also defines "wx", "wbx", "w+x" and "w+bx".