Why does printf not flush after the call unless a newline is in the format string? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) The Ask Question Wizard is Live! Data science time! April 2019 and salary with experienceResults of printf() and system() are in the wrong order when output is redirected to a filesleep inside for loophow to sleep in c“printf” doesn't print a string immediatlyIssue in C language using 'fgets' after 'printf' as 'fgets' runs before 'printf'sleep() delays output until endprintf without n does not display text when placed before while(1)How adding a New line in print statement can change way of output?simple c program not printing outputprintf on Linux vs WindowsImprove INSERT-per-second performance of SQLite?Printf example in bash does not create a newlineHow often does python flush to a file?Does printf always flush the buffer on encountering a newline?printf without n does not display text when placed before while(1)Why does C's printf format string have both %c and %s?Issue in C language using 'fgets' after 'printf' as 'fgets' runs before 'printf'“printf” doesn't print a string immediatlyWhy does stdout need explicit flushing when redirected to file?Is adding the newline character to printf() equivalent to flushing the stream?
Single author papers against my advisor's will?
Who can trigger ship-wide alerts in Star Trek?
Can't figure this one out.. What is the missing box?
What's the difference between (size_t)-1 and ~0?
What is the electric potential inside a point charge?
Strange behaviour of Check
How do I automatically answer y in bash script?
How do you clear the ApexPages.getMessages() collection in a test?
Can the prologue be the backstory of your main character?
Is above average number of years spent on PhD considered a red flag in future academia or industry positions?
Stars Make Stars
How many spell slots should a Fighter 11/Ranger 9 have?
What kind of display is this?
Need a suitable toxic chemical for a murder plot in my novel
Keep going mode for require-package
How did the aliens keep their waters separated?
Notation for two qubit composite product state
How to retrograde a note sequence in Finale?
I'm having difficulty getting my players to do stuff in a sandbox campaign
If I can make up priors, why can't I make up posteriors?
Windows 10: How to Lock (not sleep) laptop on lid close?
Why is "Captain Marvel" translated as male in Portugal?
Is there a documented rationale why the House Ways and Means chairman can demand tax info?
Is there folklore associating late breastfeeding with low intelligence and/or gullibility?
Why does printf not flush after the call unless a newline is in the format string?
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
The Ask Question Wizard is Live!
Data science time! April 2019 and salary with experienceResults of printf() and system() are in the wrong order when output is redirected to a filesleep inside for loophow to sleep in c“printf” doesn't print a string immediatlyIssue in C language using 'fgets' after 'printf' as 'fgets' runs before 'printf'sleep() delays output until endprintf without n does not display text when placed before while(1)How adding a New line in print statement can change way of output?simple c program not printing outputprintf on Linux vs WindowsImprove INSERT-per-second performance of SQLite?Printf example in bash does not create a newlineHow often does python flush to a file?Does printf always flush the buffer on encountering a newline?printf without n does not display text when placed before while(1)Why does C's printf format string have both %c and %s?Issue in C language using 'fgets' after 'printf' as 'fgets' runs before 'printf'“printf” doesn't print a string immediatlyWhy does stdout need explicit flushing when redirected to file?Is adding the newline character to printf() equivalent to flushing the stream?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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
add a comment |
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
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 fixsetvbuf(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 ofstdoutthat may flush when seeing a newline (if it's line-buffered). It would react the same way toputchar('n');, soprintf(..)is not special in this regard. This is in contrast withcout << 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
add a comment |
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
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
c printf flush
edited Jul 24 '18 at 17:18
K DawG
6,93182358
6,93182358
asked Nov 11 '09 at 16:22
Crazy ChenzCrazy Chenz
4,833104057
4,833104057
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 fixsetvbuf(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 ofstdoutthat may flush when seeing a newline (if it's line-buffered). It would react the same way toputchar('n');, soprintf(..)is not special in this regard. This is in contrast withcout << 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
add a comment |
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 fixsetvbuf(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 ofstdoutthat may flush when seeing a newline (if it's line-buffered). It would react the same way toputchar('n');, soprintf(..)is not special in this regard. This is in contrast withcout << 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
add a comment |
9 Answers
9
active
oldest
votes
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);
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 usingsetlinebuf()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
|
show 8 more comments
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
setbufandsetvbuffunctions.
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 withmyprog >/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
add a comment |
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.
add a comment |
To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).
25
Keep in mindfflush(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
add a comment |
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
2
Worse thanprintfgoing immediately to the terminal in the "normal" case is the fact thatprintfandfprintfget 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
add a comment |
stdout is buffered, so will only output after a newline is printed.
To get immediate output, either:
- Print to stderr.
- Make stdout unbuffered.
6
Orfflush(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 tostderr(this answer mentions later),fflush(stdout),fflush(NULL).
– chux
Dec 22 '17 at 10:20
add a comment |
by default, stdout is line buffered, stderr is none buffered and file is completely buffered.
add a comment |
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.
add a comment |
Use setbuf(stdout, NULL); to disable buffering.
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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);
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 usingsetlinebuf()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
|
show 8 more comments
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);
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 usingsetlinebuf()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
|
show 8 more comments
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);
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);
edited Nov 11 '09 at 20:24
answered Nov 11 '09 at 17:04
Rudd ZwolinskiRudd Zwolinski
15.3k144858
15.3k144858
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 usingsetlinebuf()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
|
show 8 more comments
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 usingsetlinebuf()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
|
show 8 more comments
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
setbufandsetvbuffunctions.
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 withmyprog >/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
add a comment |
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
setbufandsetvbuffunctions.
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 withmyprog >/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
add a comment |
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
setbufandsetvbuffunctions.
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
setbufandsetvbuffunctions.
edited Nov 17 '10 at 3:58
answered Nov 17 '10 at 3:52
paxdiablopaxdiablo
644k17712691692
644k17712691692
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 withmyprog >/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
add a comment |
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 withmyprog >/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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 11 '09 at 17:54
Southern HospitalitySouthern Hospitality
1,0171711
1,0171711
add a comment |
add a comment |
To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).
25
Keep in mindfflush(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
add a comment |
To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).
25
Keep in mindfflush(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
add a comment |
To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).
To immediately flush call fflush(stdout) or fflush(NULL) (NULL means flush everything).
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 mindfflush(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
add a comment |
25
Keep in mindfflush(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
add a comment |
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
2
Worse thanprintfgoing immediately to the terminal in the "normal" case is the fact thatprintfandfprintfget 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
add a comment |
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
2
Worse thanprintfgoing immediately to the terminal in the "normal" case is the fact thatprintfandfprintfget 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
add a comment |
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
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
edited Oct 14 '13 at 20:36
Jack
110k26187293
110k26187293
answered Oct 26 '10 at 20:47
RenatoRenato
14112
14112
2
Worse thanprintfgoing immediately to the terminal in the "normal" case is the fact thatprintfandfprintfget 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
add a comment |
2
Worse thanprintfgoing immediately to the terminal in the "normal" case is the fact thatprintfandfprintfget 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
add a comment |
stdout is buffered, so will only output after a newline is printed.
To get immediate output, either:
- Print to stderr.
- Make stdout unbuffered.
6
Orfflush(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 tostderr(this answer mentions later),fflush(stdout),fflush(NULL).
– chux
Dec 22 '17 at 10:20
add a comment |
stdout is buffered, so will only output after a newline is printed.
To get immediate output, either:
- Print to stderr.
- Make stdout unbuffered.
6
Orfflush(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 tostderr(this answer mentions later),fflush(stdout),fflush(NULL).
– chux
Dec 22 '17 at 10:20
add a comment |
stdout is buffered, so will only output after a newline is printed.
To get immediate output, either:
- Print to stderr.
- Make stdout unbuffered.
stdout is buffered, so will only output after a newline is printed.
To get immediate output, either:
- Print to stderr.
- Make stdout unbuffered.
answered Nov 11 '09 at 16:25
Douglas LeederDouglas Leeder
44.3k879120
44.3k879120
6
Orfflush(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 tostderr(this answer mentions later),fflush(stdout),fflush(NULL).
– chux
Dec 22 '17 at 10:20
add a comment |
6
Orfflush(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 tostderr(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
add a comment |
by default, stdout is line buffered, stderr is none buffered and file is completely buffered.
add a comment |
by default, stdout is line buffered, stderr is none buffered and file is completely buffered.
add a comment |
by default, stdout is line buffered, stderr is none buffered and file is completely buffered.
by default, stdout is line buffered, stderr is none buffered and file is completely buffered.
answered Jul 29 '10 at 2:02
wosowoso
20136
20136
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 11 '09 at 16:26
Rasmus KajRasmus Kaj
3,1611521
3,1611521
add a comment |
add a comment |
Use setbuf(stdout, NULL); to disable buffering.
add a comment |
Use setbuf(stdout, NULL); to disable buffering.
add a comment |
Use setbuf(stdout, NULL); to disable buffering.
Use setbuf(stdout, NULL); to disable buffering.
answered May 31 '15 at 3:22
dnahc araknayirpdnahc araknayirp
9114
9114
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 ofstdoutthat may flush when seeing a newline (if it's line-buffered). It would react the same way toputchar('n');, soprintf(..)is not special in this regard. This is in contrast withcout << 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