End of file (EOF) in C

Question

I am currently reading a C programming book in Ritchie and Kernighan. And I'm pretty confused about using EOF in the getchar() function.

First, I want to know why the value of EOF is -1 and why the value of getchar()!=EOF is 0. I apologize for my question, but I really don't understand. I really tried, but I can’t.

Then I tried to run an example in a book that can count the number of characters using the code below, but it seems like I never exit the loop, even if I press the enter button, so I wonder when I can get to EOF

 main(){ long nc; nc = 0; while (getchar() != EOF) ++nc; printf("%ld\n", nc); } 

Then I read the same problem in EOF issue in C. Most people have advised that instead of using EOF, use the terminator \ n or the null terminator '\ 0', which makes a lot of sense.

Does this mean that the example in the book serves a different purpose?

Answer 1

EOF indicates "end of file". The new line (this is what happens when you press the enter key) is not the end of the file, this is the end of the line, so the new line does not end this cycle.

The code is not flawed [*], it just does not do what you expect. It reads to the end of the input, but you seem to want to read only to the end of the line.

The EOF value is -1 because it must be different from any return value from getchar , which is the actual character. Thus, getchar returns any character value as an unsigned char converted to int, so it will be non-negative.

If you type on the terminal and want to provoke the end of the file, use CTRL-D (systems with a unified style) or CTRL-Z (Windows). Then, after all the data has been read, getchar() will return EOF , and therefore getchar() != EOF will be false and the loop will end.

[*] well, it has undefined behavior if the input is larger than LONG_MAX characters due to integer overflow, but we can probably forgive this in a simple example.

Answer 2

EOF is -1 because it is defined. The name is provided by the standard library headers that you #include . They make it equal to -1, because it must be something that cannot be mistaken for the actual byte read by getchar() . getchar() reports the actual bytes using a positive number (from 0 to 255 inclusive), so -1 is great for this.

The != Operator means not equal. 0 means false, and everything else is true. So what happens, we call the getchar() function and compare the result with -1 (EOF). If the result was not equal to EOF, then the result will be true, because things that are not equal are not equal. If the result was equal to EOF, then the result will be false, because all the same are not (not equal).

The getchar() call returns EOF when you reach the "end of file". As for C, the "standard input" (the data that you pass to your program by entering in the command window) is exactly the same as the file. Of course, you can always enter more, so you need an explicit way to say "I am done." On Windows systems, this is control-Z. On Unix systems, this is control-D.

The example in the book is not "wrong." It depends on what you really want to do . Reading until EOF means you are reading everything until the user says “I am done” and then you can no longer read. Reading to '\ n' means that you are reading an input line. Reading up to '\ 0' is a bad idea if you expect the user to type input because it is either difficult or impossible to create this byte using the keyboard on the command line :)

Answer 3

That is a lot of questions.

• Why EOF is -1: usually -1 in POSIX system calls return on error, so I assume the idea "EOF is some error"

• any logical operation (including! =) returns 1 if it is TRUE, and 0 if it is FALSE, so getchar() != EOF is 0 when it is FALSE, i.e. getchar() returns EOF .

• to emulate EOF when reading from stdin press Ctrl + D