Where timing between outputs matters, does the solution need to account for buffering?

Question

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 code-golf 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?

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.