开发者

Does reading from stdin flush stdout?

stdout is line-buffered when connected to a terminal, but I remember reading somewhere that reading (at least from stdin) will automatically flush stdout. All C implementations that I have used have done this, but I can't find it in the standard now.

It does make sense that it works that way, otherwise code like this:

printf("Type some input: ");
fgets(line, sizeof line, stdin);

would need an extra fflush(stdout);

So is stdout guaranteed to be flushed here?

EDIT:

As several replies have said, there seems to be no guarantee in the开发者_高级运维 standard that the output to stdout in my example will appear before the read from stdin, but on the other hand, this intent is stated in (my free draft copy of) the standard:

The input and output dynamics of interactive devices shall take place as specified in 7.19.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages actually appear prior to a program waiting for input.

(ISO/IEC 9899:TC2 Committee Draft -- May 6, 2005, page 14).

So it seems that there is no guarantee, but it will probably work in most implementations anyway. (Famous last words...)


No, it does not.


To answer your question, you do need the extra fflush(stdout); after your printf() call to make sure the prompt appears before your program tries to read input. Reading from stdin doesn't fflush(stdout); for you.


No. You need to fflush(stdout); Many implementations will flush at every newline of they are sending output to a terminal.


No. stdin/stdout are buffered. You need to explicity fflush(stdout) in order for the buffered data in the video memory/unix terminal's memory to be pushed out on to a view device such as a terminal. The buffering of the data can be set by calling setvbuf.

Edit: Thanks Jonathan, to answer the question, reading from stdin does not flush stdout. I may have gone off a tangent here by specifying the code demonstrating how to use setvbuf.

  #include 

  int main(void)
  {
     FILE *input, *output;
     char bufr[512];

     input = fopen("file.in", "r+b");
     output = fopen("file.out", "w");

     /* set up input stream for minimal disk access,
        using our own character buffer */
     if (setvbuf(input, bufr, _IOFBF, 512) != 0)
        printf("failed to set up buffer for input file\n");
     else
        printf("buffer set up for input file\n");

     /* set up output stream for line buffering using space that
        will be obtained through an indirect call to malloc */
     if (setvbuf(output, NULL, _IOLBF, 132) != 0)
        printf("failed to set up buffer for output file\n");
     else
        printf("buffer set up for output file\n");

     /* perform file I/O here */

     /* close files */
     fclose(input);
     fclose(output);
     return 0;
  }

Hope this helps, Best regards, Tom.


No, that's not part of the standard. It's certainly possible that you've used a library implementation where the behavior you described did happen, but that's a non-standard extension that you shouldn't rely on.


No. Watch out for inter-process deadlocks when dealing with std streams when either read on stdin or write on stdout blocks.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜