It's customary for stderr to be unbuffered while stdout is usually line
buffered or fully buffered. These properties can of course be changed
from within the program by using setvbuf.
Note that the buffer supplied to setvbuf() needs to have a lifetime at
least as much as the file stream.
The contents of the buffer are indeterminate. (n1256 - 7.19.5.6 p2)
stdin is also an input stream, while stdout and stderr are output
streams.
That can also be changed from within the program with 'freopen', and
it's in fact the most common usage of the function.
'stdin, 'stdout', 'stderr' need not to be modifiable lvalues.
fclose(stdout); /* so far so good */
stdout = fopen("helloworld", "w"); /* bad */
Imagine this case:
#define stdout __stream(1)
inline FILE *__stream(size_t i) { return __file
; }
stdout = fopen("helloworld", "w"); /* constraint violation, requires
diagnostic by the compiler */
A common mistake is to flush stdin, 'fflush(stdin)' which invokes
undefined behavior.
'stdin' doesn't need to be flushed. "flushing" input streams doesn't
make sense. Typically one wants to read until a newline or EOF is met
and discard those characters, which could be written as:
int foo(FILE *stream) { int c; while((c = getc(stream)) != EOF && c !=
'\n'); return c; }
The standard doesn't mention what kind of files 'stdin', 'stdout',
'stderr' are. In fact, the standard does not require these to be valid
files. (not *file streams* - they do need to be valid file streams)
It could be that all file operations on these three predefined streams
failed, however I'm not aware of such implementation.
The programmer needs not to know what kind of files they are either;
Just perform the normal checking of the file functions.
(offtopic: with a standard like POSIX it's also possible to see the
value of errno for more information on *why* the operation failed, ISO
C99 defines only three macros, EDOM, EILSEQ, ERANGE which are not
relevant to file operations. 7.5 p2. Try comp.unix.programmer if you
are interested to learn about POSIX)