Hacker News Reader

Hacker News

Comment by pjscott | Hacker News Reader

Full thread

pjscott

I am slightly bothered by the lack of a '\n'.

View on HN

You're not the only one.

Think of it as an open ending, there is still much more to come.

Yes, but what better metaphor for new beginnings than a "new line"? :-)

As both programmer and journalist, I can guess what happened behind the scenes. The author probably originally put in the newline into his headline but was overruled by the editor who felt that it would have distracted too many non-technical people. You and I see the correctness of the \n but a non-programmer will just see it as strange noise or punctuation.

He allowed him the C statement but kept it simplified - a good compromise I think.

I'm more bothered by the lack of #include and abysmal function signature.

My first thought, too.

Quite surprising, though, at least as Wikipedia claims¹, this (except for the lack of "\n") was the exact "hello world" code from the first edition of K&R.

____

¹) http://en.wikipedia.org/wiki/C_(programming_language)#.22Hel... and I don't have any copy of the first edition.

I'm glad you said that. I thought it was just me.

Why?

The code

    printf("goodbye, Dennis");

would give

    $ ./goodbye
    goodbye, Dennis$

What you want is to add a newline ('\n') at the end:

    printf("goodbye, Dennis\n");

Now you get

    $ ./goodbye
    goodbye, Dennis
    $

That's why the canonical "hello, world" program contains the line

    printf("hello, world\n");

"\n" is a linebreak which would guarantee the text is printed and place whatever output came afterwards on the next line.

Isn't the output stream at least guaranteed to be flushed once on completion of the program, though?

Yes, it flushes completely outputting all characters. None of which contain a newline.

Flushing doesn't automatically add newlines for you in C. It flushes the buffers you gave it, it doesn't make new stuff up to print out along with your buffers.

(Right, I didn't mean to suggest it added a newline; just that adding a newline flushes the buffer, which was one half of the problem with missing a newline—but that if this is the only line of the program, this half of the problem is obviated.)

Adding a newline doesn't flush anything. You'd want to call fflush() to do that.

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;
  }

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.

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.

"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?

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.

Reply on news.ycombinator.com