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

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?

• 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 Mar 30 '19 at 11:44

• Unfortunately, C is the exact case where all output is buffered until a <LF> character is written or the buffer is explicitly flushed...