Default input and output buffering for fopen'd files?

Question

Thus, a FILE stream can have both input and output buffers. You can configure the output stream using setvbuf (I don't know about any way to play with the size and behavior of the input buffer).

Also, the default buffer is BUFSIZ (not sure if it is a POSIX or C object). It is very clear what this means for stdin / stdout / stderr , but what are the default values ​​for newly opened files? Are they buffered for both input and output? Or maybe just one?

If it is buffered, does it default to block or row mode?

EDIT: I did some tests to find out how Jonathan Leffler responds to real world programs. It seems that if you read, then write. Writing will cause the unused portion of the input buffer to drop completely. In fact, there will be some attempts to be made to keep things at the correct file offsets. I used this simple test program:

 /* input file contains "ABCDEFGHIJKLMNOPQRSTUVWXYZ" */ #include <stdio.h> #include <stdlib.h> int main() { FILE *f = fopen("test.txt", "r+b"); char ch; fread(&ch, 1, 1, f); fwrite("test", 4, 1, f); fclose(f); return 0; } 

led to the following system calls:

 read(3, "ABCDEFGHIJKLMNOPQRSTUVWXYZ\n", 4096) = 27 // attempt to read 4096 chars, got 27 lseek(3, -26, SEEK_CUR) = 1 // at this point, I've done my write already, so forget the 26 chars I never asked for and seek to where I should be if we really just read one character... write(3, "test", 4) = 4 // and write my test close(3) = 0 

Although these are clearly implementation details, I found them very interesting as far as the standard library could be implemented. Thanks to Jonathan for your insightful answer.

Answer 1

One file stream has one buffer. If the file is used for both input and output, you must ensure that you perform the appropriate operations (fseek () or equivalents) between the read and write (or write and read) operations.

Buffering of standard channels is platform dependent.

Typically, stdout is a string buffer when the output goes to the terminal. However, if stdout is sent to a file or channel, rather than to a terminal, it usually switches to full buffering.

Typically, stderr is either buffered or unbuffered to make sure that error messages are visible (for example, even if the program is about to crash).

Typically, stdin is a string buffer; this means that you get the opportunity to edit your input (return to errors, etc.). You would rarely correct this. Again, if the input comes from a file (or channel), the behavior may be different.

Newly opened files will usually be fully buffered. A particular implementation may change this to line buffering if the device is a terminal.

Your premise — the presence of two buffers — is incorrect.

---

Section 7.19.3 C99, it reads:

When the program starts, three text streams are predefined and they obviously do not need to be opened - standard input (for reading a normal input), standard output (for writing a traditional output) and standard error (for recording diagnostic output). As originally opened, the standard error stream is not fully buffered; standard input and standard output streams are fully buffered if and only if the stream can be determined so as not to refer to the interactive device.

So, as originally stated, stderr is either unbuffered or buffered in a string (it is not fully buffered).