CATEGORY:
    Unexpected behavior due to stream buffering.
    
REFERENCE: 
    -

EXPLANATION:
    Usually, standard output (stdout) is buffered for efficiency. As a result,
    write operations first go to memory and not immediately to the device.
    Depending on which buffering strategy is employed, data will not be
    committed to the device until a) the buffer is explicitly flushed, b) the
    buffer is full, or c) the code emits a newline character.

CONSEQUENCES:
    The program outputs 2 * 3 * 100 characters (including separating spaces) in
    total, which is less than the typical buffer size. Therefore, on most
    platforms, no output will appear on the screen before the program
    terminates. At program termination, all buffered characters will be
    outputted at once. 
    
    If programmers are not aware of buffering effects, they will likely abort
    the program after a couple of seconds and believe that the code (or even
    worse, the compiler or the implementation of the standard library) is buggy.

BUGFIX:
    One simple possibility is to emit a newline character after the '+'/'-'
    characters instead of a space:

    for (i = 0; i < 100; ++i) {
        printf(" %s\n", info->msg);  // Newline will flush the buffer.
        sleep(info->sleepSecs);
    }

    The obvious downside of this approach is that it is not in line with
    original desire to put the output on a single line. If the original layout
    of the output needs to be kept, buffering of stdout can be explicitly
    disabled via the standard library function setvbuf:

    int main(int argc, char* argv[])
    {
        setvbuf(stdout, 0, _IONBF, 0);  // No buffering for standard output.

    Yet another 'fix', one that doesn't require any changes to the code, is
    executing the program through the Linux standard stdbuf utility, which
    allows the user to specify the buffer sizes of the standard streams:

    stdbuf -o0 my_program  # Sets stdout buffer size to 0.

REMARKS:
    One could argue that this example is 100% error-free and works as expected,
    at least from a buffering-savvy developer's point of view. Still, it didn't
    meet the expectations of the original author and thus can rightly be called
    buggy.