Why does printf not flush after the call unless a newline is in the format string?












472















Why does printf not flush after the call unless a newline is in the format string? Is this POSIX behavior? How might I have printf immediately flush every time?










share|improve this question




















  • 2





    did you investigated whether this happens with any file or only with terminals? that would sound to be a clever terminal feature not to output uncompleted line from a background program, though i expect it wouldn't apply to the foreground program.

    – PypeBros
    Nov 12 '09 at 16:50






  • 6





    Under Cygwin bash I'm seeing this same misbehaviour even if a newline is in the format string. This problem is new to Windows 7; the same source code worked fine on Windows XP. MS cmd.exe flushes as expected. The fix setvbuf(stdout, (char*)NULL, _IONBF, 0) works around the problem, but surely should not have been necessary. I'm using MSVC++ 2008 Express. ~~~

    – Steve Pitchers
    Jan 8 '13 at 14:10






  • 9





    To clarify the title of the question: printf(..) does not do any flushing itself, it's the buffering of stdout that may flush when seeing a newline (if it's line-buffered). It would react the same way to putchar('n');, so printf(..) is not special in this regard. This is in contrast with cout << endl;, the documentation of which prominently mentions flushing. The documentation of printf doesn't mention flushing at all.

    – Evgeni Sergeev
    Apr 5 '16 at 14:02








  • 1





    writing (/flushing) is potentially an expensive operation, it's probably buffered for performance reasons.

    – hanshenrik
    Aug 17 '17 at 23:31


















472















Why does printf not flush after the call unless a newline is in the format string? Is this POSIX behavior? How might I have printf immediately flush every time?










share|improve this question




















  • 2





    did you investigated whether this happens with any file or only with terminals? that would sound to be a clever terminal feature not to output uncompleted line from a background program, though i expect it wouldn't apply to the foreground program.

    – PypeBros
    Nov 12 '09 at 16:50






  • 6





    Under Cygwin bash I'm seeing this same misbehaviour even if a newline is in the format string. This problem is new to Windows 7; the same source code worked fine on Windows XP. MS cmd.exe flushes as expected. The fix setvbuf(stdout, (char*)NULL, _IONBF, 0) works around the problem, but surely should not have been necessary. I'm using MSVC++ 2008 Express. ~~~

    – Steve Pitchers
    Jan 8 '13 at 14:10






  • 9





    To clarify the title of the question: printf(..) does not do any flushing itself, it's the buffering of stdout that may flush when seeing a newline (if it's line-buffered). It would react the same way to putchar('n');, so printf(..) is not special in this regard. This is in contrast with cout << endl;, the documentation of which prominently mentions flushing. The documentation of printf doesn't mention flushing at all.

    – Evgeni Sergeev
    Apr 5 '16 at 14:02








  • 1





    writing (/flushing) is potentially an expensive operation, it's probably buffered for performance reasons.

    – hanshenrik
    Aug 17 '17 at 23:31
















472












472








472


165






Why does printf not flush after the call unless a newline is in the format string? Is this POSIX behavior? How might I have printf immediately flush every time?










share|improve this question
















Why does printf not flush after the call unless a newline is in the format string? Is this POSIX behavior? How might I have printf immediately flush every time?







c printf flush






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 24 '18 at 17:18









K DawG

6,92682358




6,92682358










asked Nov 11 '09 at 16:22









Crazy ChenzCrazy Chenz

4,808104057




4,808104057








  • 2





    did you investigated whether this happens with any file or only with terminals? that would sound to be a clever terminal feature not to output uncompleted line from a background program, though i expect it wouldn't apply to the foreground program.

    – PypeBros
    Nov 12 '09 at 16:50






  • 6





    Under Cygwin bash I'm seeing this same misbehaviour even if a newline is in the format string. This problem is new to Windows 7; the same source code worked fine on Windows XP. MS cmd.exe flushes as expected. The fix setvbuf(stdout, (char*)NULL, _IONBF, 0) works around the problem, but surely should not have been necessary. I'm using MSVC++ 2008 Express. ~~~

    – Steve Pitchers
    Jan 8 '13 at 14:10






  • 9





    To clarify the title of the question: printf(..) does not do any flushing itself, it's the buffering of stdout that may flush when seeing a newline (if it's line-buffered). It would react the same way to putchar('n');, so printf(..) is not special in this regard. This is in contrast with cout << endl;, the documentation of which prominently mentions flushing. The documentation of printf doesn't mention flushing at all.

    – Evgeni Sergeev
    Apr 5 '16 at 14:02








  • 1





    writing (/flushing) is potentially an expensive operation, it's probably buffered for performance reasons.

    – hanshenrik
    Aug 17 '17 at 23:31
















  • 2





    did you investigated whether this happens with any file or only with terminals? that would sound to be a clever terminal feature not to output uncompleted line from a background program, though i expect it wouldn't apply to the foreground program.

    – PypeBros
    Nov 12 '09 at 16:50






  • 6





    Under Cygwin bash I'm seeing this same misbehaviour even if a newline is in the format string. This problem is new to Windows 7; the same source code worked fine on Windows XP. MS cmd.exe flushes as expected. The fix setvbuf(stdout, (char*)NULL, _IONBF, 0) works around the problem, but surely should not have been necessary. I'm using MSVC++ 2008 Express. ~~~

    – Steve Pitchers
    Jan 8 '13 at 14:10






  • 9





    To clarify the title of the question: printf(..) does not do any flushing itself, it's the buffering of stdout that may flush when seeing a newline (if it's line-buffered). It would react the same way to putchar('n');, so printf(..) is not special in this regard. This is in contrast with cout << endl;, the documentation of which prominently mentions flushing. The documentation of printf doesn't mention flushing at all.

    – Evgeni Sergeev
    Apr 5 '16 at 14:02








  • 1





    writing (/flushing) is potentially an expensive operation, it's probably buffered for performance reasons.

    – hanshenrik
    Aug 17 '17 at 23:31










2




2





did you investigated whether this happens with any file or only with terminals? that would sound to be a clever terminal feature not to output uncompleted line from a background program, though i expect it wouldn't apply to the foreground program.

– PypeBros
Nov 12 '09 at 16:50





did you investigated whether this happens with any file or only with terminals? that would sound to be a clever terminal feature not to output uncompleted line from a background program, though i expect it wouldn't apply to the foreground program.

– PypeBros
Nov 12 '09 at 16:50




6




6





Under Cygwin bash I'm seeing this same misbehaviour even if a newline is in the format string. This problem is new to Windows 7; the same source code worked fine on Windows XP. MS cmd.exe flushes as expected. The fix setvbuf(stdout, (char*)NULL, _IONBF, 0) works around the problem, but surely should not have been necessary. I'm using MSVC++ 2008 Express. ~~~

– Steve Pitchers
Jan 8 '13 at 14:10





Under Cygwin bash I'm seeing this same misbehaviour even if a newline is in the format string. This problem is new to Windows 7; the same source code worked fine on Windows XP. MS cmd.exe flushes as expected. The fix setvbuf(stdout, (char*)NULL, _IONBF, 0) works around the problem, but surely should not have been necessary. I'm using MSVC++ 2008 Express. ~~~

– Steve Pitchers
Jan 8 '13 at 14:10




9




9





To clarify the title of the question: printf(..) does not do any flushing itself, it's the buffering of stdout that may flush when seeing a newline (if it's line-buffered). It would react the same way to putchar('n');, so printf(..) is not special in this regard. This is in contrast with cout << endl;, the documentation of which prominently mentions flushing. The documentation of printf doesn't mention flushing at all.

– Evgeni Sergeev
Apr 5 '16 at 14:02







To clarify the title of the question: printf(..) does not do any flushing itself, it's the buffering of stdout that may flush when seeing a newline (if it's line-buffered). It would react the same way to putchar('n');, so printf(..) is not special in this regard. This is in contrast with cout << endl;, the documentation of which prominently mentions flushing. The documentation of printf doesn't mention flushing at all.

– Evgeni Sergeev
Apr 5 '16 at 14:02






1




1





writing (/flushing) is potentially an expensive operation, it's probably buffered for performance reasons.

– hanshenrik
Aug 17 '17 at 23:31







writing (/flushing) is potentially an expensive operation, it's probably buffered for performance reasons.

– hanshenrik
Aug 17 '17 at 23:31














9 Answers
9






active

oldest

votes


















611














The stdout stream is buffered, so will only display what's in the buffer after it reaches a newline (or when it's told to). You have a few options to print immediately:



Print to stderr instead using fprintf:



fprintf(stderr, "I will be printed immediately");


Flush stdout whenever you need it to using fflush:



printf("Buffered, will be flushed");
fflush(stdout); // Will now print everything in the stdout buffer


Edit: From Andy Ross's comment below, you can also disable buffering on stdout by using setbuf:



setbuf(stdout, NULL);





share|improve this answer





















  • 242





    Or, to disable buffering entirely: setbuf(stdout, NULL);

    – Andy Ross
    Nov 11 '09 at 17:42






  • 67





    Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.

    – hora
    Mar 5 '11 at 23:10






  • 4





    I feel that I should add: I've just been testing this theory, and I am finding that using setlinebuf() on a stream which is not directed to a terminal is flushing at the end of each line.

    – Doddy
    Sep 6 '11 at 19:06






  • 7





    "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" -- see this question: stackoverflow.com/questions/5229096/…

    – Seppo Enarvi
    May 22 '15 at 7:23






  • 1





    @RuddZwolinski If this is going to be a good canon answer of "why isn't it printing" it seems important to mention the terminal/file distinction as per "Does printf always flush the buffer on encountering a newline?" directly in this highly upvoted answer, vs people needing to read the comments...

    – HostileFork
    Apr 8 '16 at 22:08



















112





+100









No, it's not POSIX behaviour, it's ISO behaviour (well, it is POSIX behaviour but only insofar as they conform to ISO).



Standard output is line buffered if it can be detected to refer to an interactive device, otherwise it's fully buffered. So there are situations where printf won't flush, even if it gets a newline to send out, such as:



myprog >myfile.txt


This makes sense for efficiency since, if you're interacting with a user, they probably want to see every line. If you're sending the output to a file, it's most likely that there's not a user at the other end (though not impossible, they could be tailing the file). Now you could argue that the user wants to see every character but there are two problems with that.



The first is that it's not very efficient. The second is that the original ANSI C mandate was to primarily codify existing behaviour, rather than invent new behaviour, and those design decisions were made long before ANSI started the process. Even ISO nowadays treads very carefully when changing existing rules in the standards.



As to how to deal with that, if you fflush (stdout) after every output call that you want to see immediately, that will solve the problem.



Alternatively, you can use setvbuf before operating on stdout, to set it to unbuffered and you won't have to worry about adding all those fflush lines to your code:



setvbuf (stdout, NULL, _IONBF, BUFSIZ);


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



ISO 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.







share|improve this answer





















  • 7





    I just came across a scenario where even there is a 'n', printf() doesn't flush. It was overcome by adding a fflush(stdout), as you mentioned here. But I am wondering the reason why 'n' failed to flush the buffer in printf().

    – Qiang Xu
    Apr 28 '12 at 19:45






  • 9





    @QiangXu, standard output is line buffered only in the case where it can be definitively determined to refer to an interactive device. So, for example, if you redirect output with myprog >/tmp/tmpfile, that is fully buffered rather than line buffered. From memory, the determination as to whether your standard output is interactive is left to the implementation.

    – paxdiablo
    Apr 29 '12 at 0:20








  • 2





    furthermore on Windows calling setvbuf(...., _IOLBF) will not work as _IOLBF is the same as _IOFBF there: msdn.microsoft.com/en-us/library/86cebhfs.aspx

    – Piotr Lopusiewicz
    Feb 5 '15 at 10:02



















26














It's probably like that because of efficiency and because if you have multiple programs writing to a single TTY, this way you don't get characters on a line interlaced. So if program A and B are outputting, you'll usually get:



program A output
program B output
program B output
program A output
program B output


This stinks, but it's better than



proprogrgraam m AB  ououtputputt
prproogrgram amB A ououtputtput
program B output


Note that it isn't even guaranteed to flush on a newline, so you should flush explicitly if flushing matters to you.






share|improve this answer































    25














    To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).






    share|improve this answer





















    • 25





      Keep in mind fflush(NULL); is usually a very bad idea. It will kill performance if you have many files open, especially in a multi-threaded environment where you'll fight with everything for locks.

      – R..
      Jun 9 '11 at 13:57



















    14














    Note: Microsoft runtime libraries do not support line buffering, so printf("will print immediatelly to terminal"):



    http://msdn.microsoft.com/en-us/library/86cebhfs.aspx






    share|improve this answer





















    • 2





      Worse than printf going immediately to the terminal in the "normal" case is the fact that printf and fprintf get more coarsely buffered even in cases where their output is put to immediate use. Unless MS has fixed things, that makes it impossible for one program to capture stderr and stdout from another and identify in what sequence things were sent to each.

      – supercat
      Aug 13 '15 at 18:37



















    11














    stdout is buffered, so will only output after a newline is printed.



    To get immediate output, either:




    1. Print to stderr.

    2. Make stdout unbuffered.






    share|improve this answer



















    • 6





      Or fflush(stdout).

      – RastaJedi
      Feb 22 '16 at 22:47






    • 2





      "so will only output after a newline is printed." Not only this but at least 4 other cases. buffer full, write to stderr (this answer mentions later), fflush(stdout), fflush(NULL).

      – chux
      Dec 22 '17 at 10:20





















    11














    by default, stdout is line buffered, stderr is none buffered and file is completely buffered.






    share|improve this answer































      10














      You can fprintf to stderr, which is unbuffered, instead. Or you can flush stdout when you want to. Or you can set stdout to unbuffered.






      share|improve this answer































        7














        Use setbuf(stdout, NULL); to disable buffering.






        share|improve this answer
























          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1716296%2fwhy-does-printf-not-flush-after-the-call-unless-a-newline-is-in-the-format-strin%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          9 Answers
          9






          active

          oldest

          votes








          9 Answers
          9






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          611














          The stdout stream is buffered, so will only display what's in the buffer after it reaches a newline (or when it's told to). You have a few options to print immediately:



          Print to stderr instead using fprintf:



          fprintf(stderr, "I will be printed immediately");


          Flush stdout whenever you need it to using fflush:



          printf("Buffered, will be flushed");
          fflush(stdout); // Will now print everything in the stdout buffer


          Edit: From Andy Ross's comment below, you can also disable buffering on stdout by using setbuf:



          setbuf(stdout, NULL);





          share|improve this answer





















          • 242





            Or, to disable buffering entirely: setbuf(stdout, NULL);

            – Andy Ross
            Nov 11 '09 at 17:42






          • 67





            Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.

            – hora
            Mar 5 '11 at 23:10






          • 4





            I feel that I should add: I've just been testing this theory, and I am finding that using setlinebuf() on a stream which is not directed to a terminal is flushing at the end of each line.

            – Doddy
            Sep 6 '11 at 19:06






          • 7





            "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" -- see this question: stackoverflow.com/questions/5229096/…

            – Seppo Enarvi
            May 22 '15 at 7:23






          • 1





            @RuddZwolinski If this is going to be a good canon answer of "why isn't it printing" it seems important to mention the terminal/file distinction as per "Does printf always flush the buffer on encountering a newline?" directly in this highly upvoted answer, vs people needing to read the comments...

            – HostileFork
            Apr 8 '16 at 22:08
















          611














          The stdout stream is buffered, so will only display what's in the buffer after it reaches a newline (or when it's told to). You have a few options to print immediately:



          Print to stderr instead using fprintf:



          fprintf(stderr, "I will be printed immediately");


          Flush stdout whenever you need it to using fflush:



          printf("Buffered, will be flushed");
          fflush(stdout); // Will now print everything in the stdout buffer


          Edit: From Andy Ross's comment below, you can also disable buffering on stdout by using setbuf:



          setbuf(stdout, NULL);





          share|improve this answer





















          • 242





            Or, to disable buffering entirely: setbuf(stdout, NULL);

            – Andy Ross
            Nov 11 '09 at 17:42






          • 67





            Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.

            – hora
            Mar 5 '11 at 23:10






          • 4





            I feel that I should add: I've just been testing this theory, and I am finding that using setlinebuf() on a stream which is not directed to a terminal is flushing at the end of each line.

            – Doddy
            Sep 6 '11 at 19:06






          • 7





            "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" -- see this question: stackoverflow.com/questions/5229096/…

            – Seppo Enarvi
            May 22 '15 at 7:23






          • 1





            @RuddZwolinski If this is going to be a good canon answer of "why isn't it printing" it seems important to mention the terminal/file distinction as per "Does printf always flush the buffer on encountering a newline?" directly in this highly upvoted answer, vs people needing to read the comments...

            – HostileFork
            Apr 8 '16 at 22:08














          611












          611








          611







          The stdout stream is buffered, so will only display what's in the buffer after it reaches a newline (or when it's told to). You have a few options to print immediately:



          Print to stderr instead using fprintf:



          fprintf(stderr, "I will be printed immediately");


          Flush stdout whenever you need it to using fflush:



          printf("Buffered, will be flushed");
          fflush(stdout); // Will now print everything in the stdout buffer


          Edit: From Andy Ross's comment below, you can also disable buffering on stdout by using setbuf:



          setbuf(stdout, NULL);





          share|improve this answer















          The stdout stream is buffered, so will only display what's in the buffer after it reaches a newline (or when it's told to). You have a few options to print immediately:



          Print to stderr instead using fprintf:



          fprintf(stderr, "I will be printed immediately");


          Flush stdout whenever you need it to using fflush:



          printf("Buffered, will be flushed");
          fflush(stdout); // Will now print everything in the stdout buffer


          Edit: From Andy Ross's comment below, you can also disable buffering on stdout by using setbuf:



          setbuf(stdout, NULL);






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 11 '09 at 20:24

























          answered Nov 11 '09 at 17:04









          Rudd ZwolinskiRudd Zwolinski

          15.2k144858




          15.2k144858








          • 242





            Or, to disable buffering entirely: setbuf(stdout, NULL);

            – Andy Ross
            Nov 11 '09 at 17:42






          • 67





            Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.

            – hora
            Mar 5 '11 at 23:10






          • 4





            I feel that I should add: I've just been testing this theory, and I am finding that using setlinebuf() on a stream which is not directed to a terminal is flushing at the end of each line.

            – Doddy
            Sep 6 '11 at 19:06






          • 7





            "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" -- see this question: stackoverflow.com/questions/5229096/…

            – Seppo Enarvi
            May 22 '15 at 7:23






          • 1





            @RuddZwolinski If this is going to be a good canon answer of "why isn't it printing" it seems important to mention the terminal/file distinction as per "Does printf always flush the buffer on encountering a newline?" directly in this highly upvoted answer, vs people needing to read the comments...

            – HostileFork
            Apr 8 '16 at 22:08














          • 242





            Or, to disable buffering entirely: setbuf(stdout, NULL);

            – Andy Ross
            Nov 11 '09 at 17:42






          • 67





            Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.

            – hora
            Mar 5 '11 at 23:10






          • 4





            I feel that I should add: I've just been testing this theory, and I am finding that using setlinebuf() on a stream which is not directed to a terminal is flushing at the end of each line.

            – Doddy
            Sep 6 '11 at 19:06






          • 7





            "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" -- see this question: stackoverflow.com/questions/5229096/…

            – Seppo Enarvi
            May 22 '15 at 7:23






          • 1





            @RuddZwolinski If this is going to be a good canon answer of "why isn't it printing" it seems important to mention the terminal/file distinction as per "Does printf always flush the buffer on encountering a newline?" directly in this highly upvoted answer, vs people needing to read the comments...

            – HostileFork
            Apr 8 '16 at 22:08








          242




          242





          Or, to disable buffering entirely: setbuf(stdout, NULL);

          – Andy Ross
          Nov 11 '09 at 17:42





          Or, to disable buffering entirely: setbuf(stdout, NULL);

          – Andy Ross
          Nov 11 '09 at 17:42




          67




          67





          Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.

          – hora
          Mar 5 '11 at 23:10





          Also, just wanted to mention that apparently in UNIX a newline will typically only flush the buffer if stdout is a terminal. If the output is being redirected to a file, a newline won't flush.

          – hora
          Mar 5 '11 at 23:10




          4




          4





          I feel that I should add: I've just been testing this theory, and I am finding that using setlinebuf() on a stream which is not directed to a terminal is flushing at the end of each line.

          – Doddy
          Sep 6 '11 at 19:06





          I feel that I should add: I've just been testing this theory, and I am finding that using setlinebuf() on a stream which is not directed to a terminal is flushing at the end of each line.

          – Doddy
          Sep 6 '11 at 19:06




          7




          7





          "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" -- see this question: stackoverflow.com/questions/5229096/…

          – Seppo Enarvi
          May 22 '15 at 7:23





          "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" -- see this question: stackoverflow.com/questions/5229096/…

          – Seppo Enarvi
          May 22 '15 at 7:23




          1




          1





          @RuddZwolinski If this is going to be a good canon answer of "why isn't it printing" it seems important to mention the terminal/file distinction as per "Does printf always flush the buffer on encountering a newline?" directly in this highly upvoted answer, vs people needing to read the comments...

          – HostileFork
          Apr 8 '16 at 22:08





          @RuddZwolinski If this is going to be a good canon answer of "why isn't it printing" it seems important to mention the terminal/file distinction as per "Does printf always flush the buffer on encountering a newline?" directly in this highly upvoted answer, vs people needing to read the comments...

          – HostileFork
          Apr 8 '16 at 22:08













          112





          +100









          No, it's not POSIX behaviour, it's ISO behaviour (well, it is POSIX behaviour but only insofar as they conform to ISO).



          Standard output is line buffered if it can be detected to refer to an interactive device, otherwise it's fully buffered. So there are situations where printf won't flush, even if it gets a newline to send out, such as:



          myprog >myfile.txt


          This makes sense for efficiency since, if you're interacting with a user, they probably want to see every line. If you're sending the output to a file, it's most likely that there's not a user at the other end (though not impossible, they could be tailing the file). Now you could argue that the user wants to see every character but there are two problems with that.



          The first is that it's not very efficient. The second is that the original ANSI C mandate was to primarily codify existing behaviour, rather than invent new behaviour, and those design decisions were made long before ANSI started the process. Even ISO nowadays treads very carefully when changing existing rules in the standards.



          As to how to deal with that, if you fflush (stdout) after every output call that you want to see immediately, that will solve the problem.



          Alternatively, you can use setvbuf before operating on stdout, to set it to unbuffered and you won't have to worry about adding all those fflush lines to your code:



          setvbuf (stdout, NULL, _IONBF, BUFSIZ);


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



          ISO 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.







          share|improve this answer





















          • 7





            I just came across a scenario where even there is a 'n', printf() doesn't flush. It was overcome by adding a fflush(stdout), as you mentioned here. But I am wondering the reason why 'n' failed to flush the buffer in printf().

            – Qiang Xu
            Apr 28 '12 at 19:45






          • 9





            @QiangXu, standard output is line buffered only in the case where it can be definitively determined to refer to an interactive device. So, for example, if you redirect output with myprog >/tmp/tmpfile, that is fully buffered rather than line buffered. From memory, the determination as to whether your standard output is interactive is left to the implementation.

            – paxdiablo
            Apr 29 '12 at 0:20








          • 2





            furthermore on Windows calling setvbuf(...., _IOLBF) will not work as _IOLBF is the same as _IOFBF there: msdn.microsoft.com/en-us/library/86cebhfs.aspx

            – Piotr Lopusiewicz
            Feb 5 '15 at 10:02
















          112





          +100









          No, it's not POSIX behaviour, it's ISO behaviour (well, it is POSIX behaviour but only insofar as they conform to ISO).



          Standard output is line buffered if it can be detected to refer to an interactive device, otherwise it's fully buffered. So there are situations where printf won't flush, even if it gets a newline to send out, such as:



          myprog >myfile.txt


          This makes sense for efficiency since, if you're interacting with a user, they probably want to see every line. If you're sending the output to a file, it's most likely that there's not a user at the other end (though not impossible, they could be tailing the file). Now you could argue that the user wants to see every character but there are two problems with that.



          The first is that it's not very efficient. The second is that the original ANSI C mandate was to primarily codify existing behaviour, rather than invent new behaviour, and those design decisions were made long before ANSI started the process. Even ISO nowadays treads very carefully when changing existing rules in the standards.



          As to how to deal with that, if you fflush (stdout) after every output call that you want to see immediately, that will solve the problem.



          Alternatively, you can use setvbuf before operating on stdout, to set it to unbuffered and you won't have to worry about adding all those fflush lines to your code:



          setvbuf (stdout, NULL, _IONBF, BUFSIZ);


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



          ISO 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.







          share|improve this answer





















          • 7





            I just came across a scenario where even there is a 'n', printf() doesn't flush. It was overcome by adding a fflush(stdout), as you mentioned here. But I am wondering the reason why 'n' failed to flush the buffer in printf().

            – Qiang Xu
            Apr 28 '12 at 19:45






          • 9





            @QiangXu, standard output is line buffered only in the case where it can be definitively determined to refer to an interactive device. So, for example, if you redirect output with myprog >/tmp/tmpfile, that is fully buffered rather than line buffered. From memory, the determination as to whether your standard output is interactive is left to the implementation.

            – paxdiablo
            Apr 29 '12 at 0:20








          • 2





            furthermore on Windows calling setvbuf(...., _IOLBF) will not work as _IOLBF is the same as _IOFBF there: msdn.microsoft.com/en-us/library/86cebhfs.aspx

            – Piotr Lopusiewicz
            Feb 5 '15 at 10:02














          112





          +100







          112





          +100



          112




          +100





          No, it's not POSIX behaviour, it's ISO behaviour (well, it is POSIX behaviour but only insofar as they conform to ISO).



          Standard output is line buffered if it can be detected to refer to an interactive device, otherwise it's fully buffered. So there are situations where printf won't flush, even if it gets a newline to send out, such as:



          myprog >myfile.txt


          This makes sense for efficiency since, if you're interacting with a user, they probably want to see every line. If you're sending the output to a file, it's most likely that there's not a user at the other end (though not impossible, they could be tailing the file). Now you could argue that the user wants to see every character but there are two problems with that.



          The first is that it's not very efficient. The second is that the original ANSI C mandate was to primarily codify existing behaviour, rather than invent new behaviour, and those design decisions were made long before ANSI started the process. Even ISO nowadays treads very carefully when changing existing rules in the standards.



          As to how to deal with that, if you fflush (stdout) after every output call that you want to see immediately, that will solve the problem.



          Alternatively, you can use setvbuf before operating on stdout, to set it to unbuffered and you won't have to worry about adding all those fflush lines to your code:



          setvbuf (stdout, NULL, _IONBF, BUFSIZ);


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



          ISO 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.







          share|improve this answer















          No, it's not POSIX behaviour, it's ISO behaviour (well, it is POSIX behaviour but only insofar as they conform to ISO).



          Standard output is line buffered if it can be detected to refer to an interactive device, otherwise it's fully buffered. So there are situations where printf won't flush, even if it gets a newline to send out, such as:



          myprog >myfile.txt


          This makes sense for efficiency since, if you're interacting with a user, they probably want to see every line. If you're sending the output to a file, it's most likely that there's not a user at the other end (though not impossible, they could be tailing the file). Now you could argue that the user wants to see every character but there are two problems with that.



          The first is that it's not very efficient. The second is that the original ANSI C mandate was to primarily codify existing behaviour, rather than invent new behaviour, and those design decisions were made long before ANSI started the process. Even ISO nowadays treads very carefully when changing existing rules in the standards.



          As to how to deal with that, if you fflush (stdout) after every output call that you want to see immediately, that will solve the problem.



          Alternatively, you can use setvbuf before operating on stdout, to set it to unbuffered and you won't have to worry about adding all those fflush lines to your code:



          setvbuf (stdout, NULL, _IONBF, BUFSIZ);


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



          ISO 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.








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 17 '10 at 3:58

























          answered Nov 17 '10 at 3:52









          paxdiablopaxdiablo

          643k17512661687




          643k17512661687








          • 7





            I just came across a scenario where even there is a 'n', printf() doesn't flush. It was overcome by adding a fflush(stdout), as you mentioned here. But I am wondering the reason why 'n' failed to flush the buffer in printf().

            – Qiang Xu
            Apr 28 '12 at 19:45






          • 9





            @QiangXu, standard output is line buffered only in the case where it can be definitively determined to refer to an interactive device. So, for example, if you redirect output with myprog >/tmp/tmpfile, that is fully buffered rather than line buffered. From memory, the determination as to whether your standard output is interactive is left to the implementation.

            – paxdiablo
            Apr 29 '12 at 0:20








          • 2





            furthermore on Windows calling setvbuf(...., _IOLBF) will not work as _IOLBF is the same as _IOFBF there: msdn.microsoft.com/en-us/library/86cebhfs.aspx

            – Piotr Lopusiewicz
            Feb 5 '15 at 10:02














          • 7





            I just came across a scenario where even there is a 'n', printf() doesn't flush. It was overcome by adding a fflush(stdout), as you mentioned here. But I am wondering the reason why 'n' failed to flush the buffer in printf().

            – Qiang Xu
            Apr 28 '12 at 19:45






          • 9





            @QiangXu, standard output is line buffered only in the case where it can be definitively determined to refer to an interactive device. So, for example, if you redirect output with myprog >/tmp/tmpfile, that is fully buffered rather than line buffered. From memory, the determination as to whether your standard output is interactive is left to the implementation.

            – paxdiablo
            Apr 29 '12 at 0:20








          • 2





            furthermore on Windows calling setvbuf(...., _IOLBF) will not work as _IOLBF is the same as _IOFBF there: msdn.microsoft.com/en-us/library/86cebhfs.aspx

            – Piotr Lopusiewicz
            Feb 5 '15 at 10:02








          7




          7





          I just came across a scenario where even there is a 'n', printf() doesn't flush. It was overcome by adding a fflush(stdout), as you mentioned here. But I am wondering the reason why 'n' failed to flush the buffer in printf().

          – Qiang Xu
          Apr 28 '12 at 19:45





          I just came across a scenario where even there is a 'n', printf() doesn't flush. It was overcome by adding a fflush(stdout), as you mentioned here. But I am wondering the reason why 'n' failed to flush the buffer in printf().

          – Qiang Xu
          Apr 28 '12 at 19:45




          9




          9





          @QiangXu, standard output is line buffered only in the case where it can be definitively determined to refer to an interactive device. So, for example, if you redirect output with myprog >/tmp/tmpfile, that is fully buffered rather than line buffered. From memory, the determination as to whether your standard output is interactive is left to the implementation.

          – paxdiablo
          Apr 29 '12 at 0:20







          @QiangXu, standard output is line buffered only in the case where it can be definitively determined to refer to an interactive device. So, for example, if you redirect output with myprog >/tmp/tmpfile, that is fully buffered rather than line buffered. From memory, the determination as to whether your standard output is interactive is left to the implementation.

          – paxdiablo
          Apr 29 '12 at 0:20






          2




          2





          furthermore on Windows calling setvbuf(...., _IOLBF) will not work as _IOLBF is the same as _IOFBF there: msdn.microsoft.com/en-us/library/86cebhfs.aspx

          – Piotr Lopusiewicz
          Feb 5 '15 at 10:02





          furthermore on Windows calling setvbuf(...., _IOLBF) will not work as _IOLBF is the same as _IOFBF there: msdn.microsoft.com/en-us/library/86cebhfs.aspx

          – Piotr Lopusiewicz
          Feb 5 '15 at 10:02











          26














          It's probably like that because of efficiency and because if you have multiple programs writing to a single TTY, this way you don't get characters on a line interlaced. So if program A and B are outputting, you'll usually get:



          program A output
          program B output
          program B output
          program A output
          program B output


          This stinks, but it's better than



          proprogrgraam m AB  ououtputputt
          prproogrgram amB A ououtputtput
          program B output


          Note that it isn't even guaranteed to flush on a newline, so you should flush explicitly if flushing matters to you.






          share|improve this answer




























            26














            It's probably like that because of efficiency and because if you have multiple programs writing to a single TTY, this way you don't get characters on a line interlaced. So if program A and B are outputting, you'll usually get:



            program A output
            program B output
            program B output
            program A output
            program B output


            This stinks, but it's better than



            proprogrgraam m AB  ououtputputt
            prproogrgram amB A ououtputtput
            program B output


            Note that it isn't even guaranteed to flush on a newline, so you should flush explicitly if flushing matters to you.






            share|improve this answer


























              26












              26








              26







              It's probably like that because of efficiency and because if you have multiple programs writing to a single TTY, this way you don't get characters on a line interlaced. So if program A and B are outputting, you'll usually get:



              program A output
              program B output
              program B output
              program A output
              program B output


              This stinks, but it's better than



              proprogrgraam m AB  ououtputputt
              prproogrgram amB A ououtputtput
              program B output


              Note that it isn't even guaranteed to flush on a newline, so you should flush explicitly if flushing matters to you.






              share|improve this answer













              It's probably like that because of efficiency and because if you have multiple programs writing to a single TTY, this way you don't get characters on a line interlaced. So if program A and B are outputting, you'll usually get:



              program A output
              program B output
              program B output
              program A output
              program B output


              This stinks, but it's better than



              proprogrgraam m AB  ououtputputt
              prproogrgram amB A ououtputtput
              program B output


              Note that it isn't even guaranteed to flush on a newline, so you should flush explicitly if flushing matters to you.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Nov 11 '09 at 17:54









              Southern HospitalitySouthern Hospitality

              1,0171711




              1,0171711























                  25














                  To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).






                  share|improve this answer





















                  • 25





                    Keep in mind fflush(NULL); is usually a very bad idea. It will kill performance if you have many files open, especially in a multi-threaded environment where you'll fight with everything for locks.

                    – R..
                    Jun 9 '11 at 13:57
















                  25














                  To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).






                  share|improve this answer





















                  • 25





                    Keep in mind fflush(NULL); is usually a very bad idea. It will kill performance if you have many files open, especially in a multi-threaded environment where you'll fight with everything for locks.

                    – R..
                    Jun 9 '11 at 13:57














                  25












                  25








                  25







                  To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).






                  share|improve this answer















                  To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Sep 25 '15 at 1:10









                  Cristian Ciupitu

                  14.9k54264




                  14.9k54264










                  answered Nov 11 '09 at 16:26









                  AaronAaron

                  7,93843538




                  7,93843538








                  • 25





                    Keep in mind fflush(NULL); is usually a very bad idea. It will kill performance if you have many files open, especially in a multi-threaded environment where you'll fight with everything for locks.

                    – R..
                    Jun 9 '11 at 13:57














                  • 25





                    Keep in mind fflush(NULL); is usually a very bad idea. It will kill performance if you have many files open, especially in a multi-threaded environment where you'll fight with everything for locks.

                    – R..
                    Jun 9 '11 at 13:57








                  25




                  25





                  Keep in mind fflush(NULL); is usually a very bad idea. It will kill performance if you have many files open, especially in a multi-threaded environment where you'll fight with everything for locks.

                  – R..
                  Jun 9 '11 at 13:57





                  Keep in mind fflush(NULL); is usually a very bad idea. It will kill performance if you have many files open, especially in a multi-threaded environment where you'll fight with everything for locks.

                  – R..
                  Jun 9 '11 at 13:57











                  14














                  Note: Microsoft runtime libraries do not support line buffering, so printf("will print immediatelly to terminal"):



                  http://msdn.microsoft.com/en-us/library/86cebhfs.aspx






                  share|improve this answer





















                  • 2





                    Worse than printf going immediately to the terminal in the "normal" case is the fact that printf and fprintf get more coarsely buffered even in cases where their output is put to immediate use. Unless MS has fixed things, that makes it impossible for one program to capture stderr and stdout from another and identify in what sequence things were sent to each.

                    – supercat
                    Aug 13 '15 at 18:37
















                  14














                  Note: Microsoft runtime libraries do not support line buffering, so printf("will print immediatelly to terminal"):



                  http://msdn.microsoft.com/en-us/library/86cebhfs.aspx






                  share|improve this answer





















                  • 2





                    Worse than printf going immediately to the terminal in the "normal" case is the fact that printf and fprintf get more coarsely buffered even in cases where their output is put to immediate use. Unless MS has fixed things, that makes it impossible for one program to capture stderr and stdout from another and identify in what sequence things were sent to each.

                    – supercat
                    Aug 13 '15 at 18:37














                  14












                  14








                  14







                  Note: Microsoft runtime libraries do not support line buffering, so printf("will print immediatelly to terminal"):



                  http://msdn.microsoft.com/en-us/library/86cebhfs.aspx






                  share|improve this answer















                  Note: Microsoft runtime libraries do not support line buffering, so printf("will print immediatelly to terminal"):



                  http://msdn.microsoft.com/en-us/library/86cebhfs.aspx







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Oct 14 '13 at 20:36









                  Jack

                  110k26187293




                  110k26187293










                  answered Oct 26 '10 at 20:47









                  RenatoRenato

                  14112




                  14112








                  • 2





                    Worse than printf going immediately to the terminal in the "normal" case is the fact that printf and fprintf get more coarsely buffered even in cases where their output is put to immediate use. Unless MS has fixed things, that makes it impossible for one program to capture stderr and stdout from another and identify in what sequence things were sent to each.

                    – supercat
                    Aug 13 '15 at 18:37














                  • 2





                    Worse than printf going immediately to the terminal in the "normal" case is the fact that printf and fprintf get more coarsely buffered even in cases where their output is put to immediate use. Unless MS has fixed things, that makes it impossible for one program to capture stderr and stdout from another and identify in what sequence things were sent to each.

                    – supercat
                    Aug 13 '15 at 18:37








                  2




                  2





                  Worse than printf going immediately to the terminal in the "normal" case is the fact that printf and fprintf get more coarsely buffered even in cases where their output is put to immediate use. Unless MS has fixed things, that makes it impossible for one program to capture stderr and stdout from another and identify in what sequence things were sent to each.

                  – supercat
                  Aug 13 '15 at 18:37





                  Worse than printf going immediately to the terminal in the "normal" case is the fact that printf and fprintf get more coarsely buffered even in cases where their output is put to immediate use. Unless MS has fixed things, that makes it impossible for one program to capture stderr and stdout from another and identify in what sequence things were sent to each.

                  – supercat
                  Aug 13 '15 at 18:37











                  11














                  stdout is buffered, so will only output after a newline is printed.



                  To get immediate output, either:




                  1. Print to stderr.

                  2. Make stdout unbuffered.






                  share|improve this answer



















                  • 6





                    Or fflush(stdout).

                    – RastaJedi
                    Feb 22 '16 at 22:47






                  • 2





                    "so will only output after a newline is printed." Not only this but at least 4 other cases. buffer full, write to stderr (this answer mentions later), fflush(stdout), fflush(NULL).

                    – chux
                    Dec 22 '17 at 10:20


















                  11














                  stdout is buffered, so will only output after a newline is printed.



                  To get immediate output, either:




                  1. Print to stderr.

                  2. Make stdout unbuffered.






                  share|improve this answer



















                  • 6





                    Or fflush(stdout).

                    – RastaJedi
                    Feb 22 '16 at 22:47






                  • 2





                    "so will only output after a newline is printed." Not only this but at least 4 other cases. buffer full, write to stderr (this answer mentions later), fflush(stdout), fflush(NULL).

                    – chux
                    Dec 22 '17 at 10:20
















                  11












                  11








                  11







                  stdout is buffered, so will only output after a newline is printed.



                  To get immediate output, either:




                  1. Print to stderr.

                  2. Make stdout unbuffered.






                  share|improve this answer













                  stdout is buffered, so will only output after a newline is printed.



                  To get immediate output, either:




                  1. Print to stderr.

                  2. Make stdout unbuffered.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 11 '09 at 16:25









                  Douglas LeederDouglas Leeder

                  44.2k878120




                  44.2k878120








                  • 6





                    Or fflush(stdout).

                    – RastaJedi
                    Feb 22 '16 at 22:47






                  • 2





                    "so will only output after a newline is printed." Not only this but at least 4 other cases. buffer full, write to stderr (this answer mentions later), fflush(stdout), fflush(NULL).

                    – chux
                    Dec 22 '17 at 10:20
















                  • 6





                    Or fflush(stdout).

                    – RastaJedi
                    Feb 22 '16 at 22:47






                  • 2





                    "so will only output after a newline is printed." Not only this but at least 4 other cases. buffer full, write to stderr (this answer mentions later), fflush(stdout), fflush(NULL).

                    – chux
                    Dec 22 '17 at 10:20










                  6




                  6





                  Or fflush(stdout).

                  – RastaJedi
                  Feb 22 '16 at 22:47





                  Or fflush(stdout).

                  – RastaJedi
                  Feb 22 '16 at 22:47




                  2




                  2





                  "so will only output after a newline is printed." Not only this but at least 4 other cases. buffer full, write to stderr (this answer mentions later), fflush(stdout), fflush(NULL).

                  – chux
                  Dec 22 '17 at 10:20







                  "so will only output after a newline is printed." Not only this but at least 4 other cases. buffer full, write to stderr (this answer mentions later), fflush(stdout), fflush(NULL).

                  – chux
                  Dec 22 '17 at 10:20













                  11














                  by default, stdout is line buffered, stderr is none buffered and file is completely buffered.






                  share|improve this answer




























                    11














                    by default, stdout is line buffered, stderr is none buffered and file is completely buffered.






                    share|improve this answer


























                      11












                      11








                      11







                      by default, stdout is line buffered, stderr is none buffered and file is completely buffered.






                      share|improve this answer













                      by default, stdout is line buffered, stderr is none buffered and file is completely buffered.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Jul 29 '10 at 2:02









                      wosowoso

                      20136




                      20136























                          10














                          You can fprintf to stderr, which is unbuffered, instead. Or you can flush stdout when you want to. Or you can set stdout to unbuffered.






                          share|improve this answer




























                            10














                            You can fprintf to stderr, which is unbuffered, instead. Or you can flush stdout when you want to. Or you can set stdout to unbuffered.






                            share|improve this answer


























                              10












                              10








                              10







                              You can fprintf to stderr, which is unbuffered, instead. Or you can flush stdout when you want to. Or you can set stdout to unbuffered.






                              share|improve this answer













                              You can fprintf to stderr, which is unbuffered, instead. Or you can flush stdout when you want to. Or you can set stdout to unbuffered.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Nov 11 '09 at 16:26









                              Rasmus KajRasmus Kaj

                              3,1511521




                              3,1511521























                                  7














                                  Use setbuf(stdout, NULL); to disable buffering.






                                  share|improve this answer




























                                    7














                                    Use setbuf(stdout, NULL); to disable buffering.






                                    share|improve this answer


























                                      7












                                      7








                                      7







                                      Use setbuf(stdout, NULL); to disable buffering.






                                      share|improve this answer













                                      Use setbuf(stdout, NULL); to disable buffering.







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered May 31 '15 at 3:22









                                      dnahc araknayirpdnahc araknayirp

                                      8114




                                      8114






























                                          draft saved

                                          draft discarded




















































                                          Thanks for contributing an answer to Stack Overflow!


                                          • Please be sure to answer the question. Provide details and share your research!

                                          But avoid



                                          • Asking for help, clarification, or responding to other answers.

                                          • Making statements based on opinion; back them up with references or personal experience.


                                          To learn more, see our tips on writing great answers.




                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function () {
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1716296%2fwhy-does-printf-not-flush-after-the-call-unless-a-newline-is-in-the-format-strin%23new-answer', 'question_page');
                                          }
                                          );

                                          Post as a guest















                                          Required, but never shown





















































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown

































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown







                                          Popular posts from this blog

                                          Monofisismo

                                          Angular Downloading a file using contenturl with Basic Authentication

                                          Olmecas