[bremac]

printf prints to standard output, which is line-buffered by default when reading from a tty on UNIX variants. This can lead to strange problems for those who try to use it to track which parts of a program are being executed, as demonstrated by the following program with an infinite loop:

  #include <stdio.h>
  int main(int c, char **v) {
    printf("Hello\nJello");
    while(1) ;
    return 0;
  }

[getsat]

Yes. You're not agreeing or disagreeing with me. Did you reply to the wrong post?

Also, using printf() for debugging? In 2011? I seriously hope you guys don't do this.

[jimbokun]

"Also, using printf() for debugging? In 2011? I seriously hope you guys don't do this."

OK, I'll bite. I haven't done any serious straight up C programming in over a decade, and yes, I used a lot of printf for debugging back then. What's the best way to debug C programs now? (I imagine printf wasn't the best way to debug programs when I was writing C, either.) A different logging library? gdb?

[getsat]

printf() is fine if you just want to see if something is being run (assuming, of course, you recognize the flushing caveat we're discussing).

If you're dumping printf()s all over the place to see exactly what flow your program is taking at runtime, you're better off just setting a breakpoint or two and using a debugger to quickly step through it.

[bremac]

Adding a newline into a line buffer (which is a user-space buffer) flushes the buffered data up to and including the newline. fflush also flushes a user space buffer. Also, the "for those" implies I'm talking about someone else, not myself.