In certain languages (i.e. C), writes to streams like stdout can be buffered by default - what this means is that when one calls functions like putchar() or printf() to produce output, it is not necessarily written to the console immediately. Instead, it is (by default) printed when a linefeed is written, the buffer is filled, the stream is closed or the buffer is explicitly flushed (i.e. fflush(stdout)).

This becomes important in certain challenges, like this one, which require a delay between outputs and where the length of the source code matters.

Consider the two ways to achieve this:

  • You flush the buffer after every write with a call, i.e. fflush(stdout);

  • or you turn off buffering for stdout, i.e. setbuf(stdout,NULL)

However, these do not come for free - especially in the 14+ extra bytes can really hurt solutions. In fact, in the challenge linked above, none of the answers in C account for stdout being buffered.

Is it acceptable to assume that streams are non-buffering, even when by default they are not? Or, in other words, do solutions need to account for output potentially being buffered?

  • 2
    \$\begingroup\$ You're fine with assuming there's no buffering - you can see the correct amount of output when terminating early so I'd say it counts \$\endgroup\$
    – ASCII-only
    Mar 30, 2019 at 11:44

1 Answer 1


It's ok iff the solution works in some configuration

For example you can specify "<language> (output to terminal)" in the header.

In my experience, even though languages have buffering by default they tend to only do line-buffer when the output is interactive, so if the code works fine when output to the terminal it's ok.

  • \$\begingroup\$ Unfortunately, C is the exact case where all output is buffered until a <LF> character is written or the buffer is explicitly flushed... \$\endgroup\$
    – user77406
    Apr 1, 2019 at 20:54

You must log in to answer this question.