Problem with example 1.5.2 in K&R book on C

I'm teaching myself C with K&R and am stumped by one of the examples in the book. I compile the code exactly as it is written in the example but it does not do what the authors say it will. The program is supposed to count characters. The code given is as follows:

#include <stdio.h>

/* count characters in input; 1st version */
main()
{
long nc;
nc=0;
while (getchar() != EOF)
++nc;
printf("%ld\n", nc);
}

For it to compile I replace main() with int main(). But I assume that is not relevant to the question. The program compiles and runs fine. But it simply does not count characters as it was written to do. Am I missing something? Could something have changed in how modern compilers treat a code example such as this since the book was written? Any assistance the good folks on this message board might be able to offer would be greatly appreciated.

Best,
Dan

The program only outputs the number of character after it read an "end of file". With interactive input, you can generate an "end of file" via ctrl+d (at least on *NIX, no idea about windows). Knowing this, the program works correctly here.

Apart from the return value of main it looks OK.

Do you do the <kbd>Ctrl</kbd><kbd>D</kbd> (Unix) or <kbd>Ctrl</kbd><kbd>Z</kbd> (Windows) at the end of input if you are entering values from keyboard?

Although the other answers are *technically* correct, I feel that this example (1.5.2) and the following one (1.5.3) are pedagogically confusing. Just google "character counting 1.5.2" and you will find many others who got caught up by this example, just as the OP did. The reason it is so confusing is that there is no explanation in the text about how to generate the EOF character in interactive mode, AND the previous examples outputted the results as soon as "return" was entered. Thus, any beginner to C would assume that the program in 1.5.3 should do the same...

I would like to propose the following alternative code, which produces the *expected* result:

#include <stdio.h>
#define EOL '\n'

main()
{
long nc;
int c;
nc = 0;

while ((c = getchar()) != EOF)
{
++nc;
if (c == EOL)
{
/* Print number of input characters (not including return character) */
printf("%ld\n", nc-1);
nc = 0;
}
}
}

The only element of C not already explained in the text is the `if` statement, which is actually explained in the very next section (1.5.3). I hope this small alternative example will serve to help others who got caught up by the original example from the K&R book. A good "Exercise 1.7b" would be to examine the differences between the two versions and explain verify that they output the same results (after reading about <kbd>Ctrl</kbd><kbd>D</kbd> / <kbd>Ctrl</kbd><kbd>Z</kbd> from the other answers).

It would also be worth noting that Ctrl + z (which will appear as ^Z in the console) cannot simply be entered anywhere in the console input; you must enter it as the first input of your final line of string/text/characters.
E.G

[Picture of initial input Ctrl + z ][1]


As you can see in this example I typed in random text and after each line ended, I pressed enter. NOW THIS IS IMPORTANT!!! When you press enter on the final line it will invoke the EOF (End-of-File) and you'll get the rest of the code executing like it was originally intended to happen.

[Fully executed code][2]

Note:

- Even though Ctrl + z appears as ^Z, it is not counted as a character by the program however many times you press it.
- Also characters after ctrl+z are not counted.
- Enter is counted by this program

Source:

[To see links please register here]

[1]:

[2]:

I had the same problem until I realised that if you type CTRL+D twice rather than once without typing carriage-return at all, the program behaves as expected. If I type 'Hello' the program outputs 'Hello5', the '5' on the end indicating that 5 characters were input. If I type carriage-return then CTRL+D after typing 'Hello', 'Hello6' is output because the program is counting the carriage return as well.

CTRL+D generates an EOF. So, the program does work, but the explanation is a little unclear since the author expected the reader to know axiomatically how to generate an EOF. That was normal at the time. I do hope this clears it up for others as it did for me. Cheers.