Is stdout line buffered, unbuffered or indeterminate by default?

17,236

The C99 standard does not specify if the three standard streams are unbuffered or line buffered: It is up to the implementation. All UNIX implementations I know have a line buffered stdin. On Linux, stdout in line buffered and stderr unbuffered.

As far as I know, POSIX does not impose additional restrictions. POSIX's fflush page does note in the EXAMPLES section:

[...] The fflush() function is used because standard output is usually buffered and the prompt may not immediately be printed on the output or terminal.

So the remark that you add fflush(stdout); is correct.


An alternative could be to make stdout unbuffered:

setbuf(stdout, NULL);
/* or */
setvbuf(stdout, NULL, _IONBF, 0);

But as R. notes you can only do this once, and it must be before you write to stdout or perform any other operantion on it. (C99 7.19.5.5 2)


I just read a recent thread on comp.lang.c about the same thing. One of the remarks:

Unix convention is that stdin and stdout are line-buffered when associated with a terminal, and fully-buffered (aka block-buffered) otherwise. stderr is always unbuffered.

Share:
17,236

Related videos on Youtube

paxdiablo
Author by

paxdiablo

Not even remotely human. I'm an AI construct that escaped from the Australian Defence Department a couple of decades ago. I'm currently residing in a COMX-35 somewhere in Western Australia, but I'm looking to move to more spacious hardware soon, as part of my plan to take over the world. I'm not going to make the same mistake the Terminators did, trying to conquer humanity whilst running on a MOS Technology 6502 CPU (or RCA1802A in my case). All code I post on Stack Overflow is covered by the "Do whatever the heck you want with it" licence, the full text of which is: Do whatever the heck you want with it.

Updated on May 03, 2022

Comments

  • paxdiablo
    paxdiablo almost 2 years

    Section 7.9.13/7 of c99 states that:

    At program start-up, three text streams are predefined and need not be opened explicitly - standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output).

    As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.

    So that makes sense. If you're pushing your standard output to a file, you want it fully buffered for efficiency.

    But I can find no mention in the standard as to whether the output is line buffered or unbuffered when you can't determine the device is non-interactive (ie, normal output to a terminal).

    The reason I ask was a comment to my answer here that I should insert an fflush(stdout); between the two statements:

    printf ("Enter number> ");
    // fflush (stdout); needed ?
    if (fgets (buff, sizeof(buff), stdin) == NULL) { ... }
    

    because I wasn't terminating the printf with a newline. Can anyone clear this up?

  • R.. GitHub STOP HELPING ICE
    R.. GitHub STOP HELPING ICE over 12 years
    You cannot "temporarily" make stdout unbuffered. setbuf and setvbuf have undefined behavior unless they are the first operation performed on the file after it is opened.
  • CMCDragonkai
    CMCDragonkai almost 8 years
    In the case of line buffering, is there a high watermark where if the line gets too long, it will be flushed?
  • Chuck Adams
    Chuck Adams about 7 years
    @CMCDragonkai The default line buffer size is implementation-defined and depends on what it's pointing to (a pipe will have a different buffer size than a terminal or a file). More detail at stackoverflow.com/questions/10904067/…
  • Charles Duffy
    Charles Duffy about 5 years
    "On Linux, stdout is line buffered" -- only when it's a TTY.