In C, what's the size of stdout buffer?

Question

Today I learned that stdout is line buffered when it's set to terminal and buffered in different cases. So, in normal situation, if I use printf() without the terminating '\n' it will be printed on the screen only when the buffer will be full. How to get a size of this buffer, how big is this?

Answer 1

The Linux when a pipe is created for default pipe size 64K is used. In /proc/sys/fs/pipe-max-size the maximum pipe size exists. For the default 1048576 is typical.

For glibc's default file buffer; 65536 bytes seems reasonable. However, ascertained by grep from the glibc source tree: libio/libio.h:#define _IO_BUFSIZ _G_BUFSIZ sysdeps/generic/_G_config.h:#define _G_BUFSIZ 8192 sysdeps/unix/sysv/linux/_G_config.h:#define _G_BUFSIZ 8192

By that the original question might or might not be answered. For a minute's effort the best guess is 8 kilobytes.

For mere line buffering 8K is adequate. However, for more than line buffered output as compared with 64K; 8K is not efficient. Because for the default pipe size 64K is used and if a larger pipe size is not expected and if a larger pipe size is not explicitly set then for a stdio buffer 64K is recommended.

If performance is required then meager 8K buffers do not suffice. By fcntl(pipefd,F_SETPIPE_SZ,1048576) a pipe's size can be increased. By setvbuf (stdout,buffer,_IOFBF,1048576) a stdio provided file buffer can be replaced. If a pipe is not used then pipe size is irrelevant. However, if between two processes data is piped then by increasing pipe size a performance boon could become. Otherwise by the smallest buffer or by the smallest pipe a bottleneck is created.

If reading also then by a larger buffer by stdio fewer read function invocations might be required. By the word "might" an important consideration is suggested. As by provided by a single write function invocation by a single read function invocation as much data can be read. By a read function invocation a return with fewer bytes than requested can be expected. By an additional read function invocation additional bytes may be gained.

For writing a data line; by stdio overkill is provided. However, by stdio line buffered output is possible. In some scenarios line buffered output is essential. If writing to a proc virtual file system provided file or if writing to a sys virtual file system provided file then in a single write buffer the line feed byte should be included. If a second write is used then an unexpected outcome could become.

If read write and stdio are mixed then caveats exist. Before a write function invocation a fflush function invocation is required. Because stderr is not buffered; for stderr the fflush function invocation is not required. By read fewer than expected bytes might be provided. By stdio the previous bytes might already be buffered.

Not mixing unistd and stdio I/O is good advise, but often ignored. Mixing buffered input is unreasonable. Mixing unbuffered input is possible. Mixing buffered output is plausible.

By stdio buffered IO convenience is provided. Without stdio buffered IO is possible. However, for the code additional bytes are required. When a sufficient sized buffer is leveraged; compared with stdio provided output functions; the write function invocation is not necessarily slower.

However, when a pipe is not involved then by function mmap superior IO can be provided. On a pipe by mmap an error is not returned. However, in the address space the data is not provided. On a pipe by lseek an error is provided.

Lastly by man 3 setvbuf a good example is provided. If on the stack the buffer is allocated then before a return a fclose function invocation must not be omitted.

The actual question was "In C, what's the size of stdout buffer?" By 8192 that much might be answered.

By those who encounter this inquiry curiosity concerning buffer input/output efficiency might exist. By some inquiries the goal is implicitly approached. By a preference for terse replies the pipe size significance and the buffer size significance and mmap is not explicated. This reply explicates.

Answer 2

The actual size is defined by the individual implementation; the standard doesn't mandate a minimum size (based on what I've been able to find, anyway). Don't have a clue on how you'd determine the size of the buffer.

Edit

Chapter and verse:

7.19.3 Files

...
3 When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible. Otherwise characters may be accumulated and transmitted to or from the host environment as a block. When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled. When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered. Furthermore, characters are intended to be transmitted as a block to the host environment when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line buffered stream that requires the transmission of characters from the host environment. Support for these characteristics is implementation-defined, and may be affected via the setbuf and setvbuf functions.

Emphasis added.

"Implementation-defined" is not a euphemism for "I don't know", it's simply a statement that the language standard explicitly leaves it up to the implementation to define the behavior.

And having said that, there is a non-programmatic way to find out; consult the documentation for your compiler. "Implementation-defined" also means that the implementation must document the behavior:

3.4.1

1 implementation-defined behavior
unspecified behavior where each implementation documents how the choice is made

2 EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right.