Can you please explain what is happening with fflush() and redirected output here?

So I wrote a test program and here is the code

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    int i;
    printf("%s", "entering\n");
    fflush(stdout);
    for (i = 0 ; i < 3 ; i++)
    {
   开发者_开发问答     fork();
        fflush(stdout);
    }

    printf("%s", "exiting\n");
}

When I compile and run it in the terminal it displays what I expect it to: "entering" once, and "exiting" some times. When I run it and redirect the output to a file it displays entering for every exiting.

1) Why does it not output the same thing to terminal and to a file every time?

2) Why does it display entering in the file 8 times but not entering in in the terminal only once (once is what I would expect it to do).

3) Do the fflush() statements make a difference when my output goes to a file?

It has to do with the buffering on the standard file handles. From ISO C99 7.19.3/7 Files:

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.

When you're writing to the terminal, the output is most likely ^(a) line-buffered, meaning it will be flushed whenever a newline is sent.

With redirection, it's fully buffered meaning it will only flush when the buffer is full.

You can use setvbuf before operating on stdout, to set it to unbuffered or line buffered, and you won't have to worry about flushing.

setvbuf (stdout, NULL, _IONBF, BUFSIZ); // _IONBF for  no  buffering.
                                        // _IOFBF for full buffering.
                                        // _IOLBF for line buffering.

Just keep in mind that unbuffered output may affect performance quite a bit if you're sending the output to a file. Also keep in mind that support for this is implementation-defined, not guaranteed by the standard.

C99 section 7.19.3/3 is the relevant bit:

When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible. Otherwise characters may be accumulated and transmitted to or from the host environment as a block.

When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled.

When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered.

Furthermore, characters are intended to be transmitted as a block to the host environment when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line buffered stream that requires the transmission of characters from the host environment.

Support for these characteristics is implementation-defined, and may be affected via the setbuf and setvbuf functions.

^(a) Whether standard input and output are unbuffered or line buffered where the underlying file is possibly interactive is not specified by the standard (see here). Line buffering is the most common (by far) from what I've encountered.

As to why you're getting multiple entering messages even though you flush it before forking, that's a trickier one. You haven't listed your environment so this is supposition at best but I see a few possibilities (although there may well be more).

Firstly, the fflush may be failing for some reason. This is actually possible but easy to check since it behaves similarly to write (because it usually calls write under the covers).

In other words, check errno after the flush to see if there's been a problem. If so, the C runtime buffers will still be unflushed in all children so they'll all write entering.

Secondly, even if the buffers are flushed, there may be more buffering going on below (at the write level or within the terminal drivers themselves) which is duplicated by the fork, resulting in multiple outputs to the terminal. I consider this unlikely.

Thirdly, this may just be a weird platform-specific issue. When I run your code on my Ubuntu 11.04 box, I see no difference between the terminal output and the file output variants. They both output one entering and eight exiting messages.

If that third one is the case then you really have no recourse: ISO C doesn't mandate what happens in this case because ISO C knows nothing of fork. I can't find anything in POSIX.1 that seems to indicate one way or another but it may be there.

For what it's worth, if I comment out only the first fflush, I get entering twice followed by eight exiting messages. If I comment out only the second, it asts the same as if they're both there, one entering followed by eight exiting.

If I comment out both of them, I get eight entering/exiting pairs.

Regarding the multiple "entering" printed, it may be a bug(?) due to your environment.

I have already noticed the following strange behavior when running a program on zsh/Cygwin/WinXP compiled with MSVC98. If the program crashes, the stdout buffer is discarded and the program is rerun a small number of time.

For instance:

#include <stdio.h>
int main(int argc, char *argv[]) {
    printf("hello\n");
    fflush(stdout);
    *(char*) 0 = 1;
}

will give on my PC:

> cl.exe crash.c
[etc...]
> ./crash.exe
hello
hello
hello
hello
hello
hello

Without the flush(), nothing is printed.

The same program compiled with gcc has a more "expected" behavior, even without the flush():

hello
zsh: segmentation fault (core dumped)  ./a.exe

No idea why. I tried to investigate a bit, but without success.