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?
Asked
Active
Viewed 2.3k times
11
-
2If you don't want the buffering, why not use one of the other standard library functions that doesn't require it? Or perhaps you could just include the `\n` terminator. – Robert Harvey Jun 05 '12 at 20:03
-
1I just don't know what's the size of the stdout buffer. I know what you said, I just want to know how much data must be collected for buffer to be regarded full and the text printed on the screen – user1042840 Jun 05 '12 at 20:12
4 Answers
11
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
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 thesetbufandsetvbuffunctions.
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.
John Bode
- 119,563
- 19
- 122
- 198
-
1I hear 'it depends on the implementation' so often that I start to think that sometimes it's just the way to say 'I don't know', but you have said that clearly, so ok ;p – user1042840 Jun 05 '12 at 20:44
-
"it depends on the implementation" means the implementer can implement it as they see fit and still compliant to the standard. if you really want to know how big that buffer is, you can keep writing into it without any "\n" til it overflows. – pizza Jun 05 '12 at 21:07
-
How can I see if buffer overflows, finally there will be no characters printed and it will start from 1 again? – user1042840 Jun 05 '12 at 21:11
-
you can print the count of the character to stderr (which is unbuffered) and see when the first buffered characters comes out, I leave the implementation as homework for you. – pizza Jun 05 '12 at 21:15
-
I wrote this http://pastebin.com/DjMnbCvy and it seems that the size of the buffer is 1024 on my x64 Slackware. – user1042840 Jun 05 '12 at 21:32
-
@John Bode: thank you for this information, I didn't want to be offensive. I have found a confirmation that buffer size is 1024 here http://www.pixelbeat.org/programming/stdio_buffering/, but on this page it says 'if stdin/stdout are connected to a terminal', what does it mean? – user1042840 Jun 05 '12 at 22:09
-
@user1042840: `stdin` and `stdout` can be redirected to point to a file or different device where the buffering strategy may be different. – John Bode Jun 06 '12 at 11:31
-
2This actually depends on the libc which you are using, not the compiler. – Alex D Aug 11 '15 at 07:44
2
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.
Carey Gregory
- 6,836
- 2
- 26
- 47
loquacious
- 31
- 1
-3
You could set it to unbuffered, or just flush it.
This seems to have some decent info when the C runtime typically flushes it for you and some examples. Take a look at this.
-
Thx, but what I would like to know is know how much data must be collected for buffer to be regarded full and the text printed on the screen in Linux or other *nik systems? What's the size of the fictional BUFFER, so often mentioned. – user1042840 Jun 05 '12 at 20:16