Thread: Misconception about EOF

  1. #1
    Registered User
    Join Date
    Nov 2011

    Misconception about EOF

    Hello. Disclaimer: this is a vexed question. At least, let me tell you that:

    - I know that EOF is the value that getchar() returns when end-of-file is reached;
    - It is not a character;
    - It's generally "-1" but it cannot be expressed typing "-1".
    - I defined the variable storing each character as int, not char.

    So, I copied and pasted this program from the Kernighan-Ritchie book:

    #include <stdio.h>
       /* copy input to output; 2nd version  */
           int c;
           while ((c = getchar()) != EOF)
    Afer this example, the authors go on to say:

    "The while gets a character, assigns it to c, and then tests whether the character was the end-of-file signal. If it was not, the body of the while is executed, printing the character. The while then repeats. When the end of the input is finally reached, the while terminates and so does main."

    This gives me to understand that, if I enter the text stream "Hello" and press Enter ("Hello\n"), getchar() will go on to read each character of the stream, which, as I see it, should be "H", "e", "l", "l", "o", "\n". Then getchar() has nothing else to read and... returns EOF? That's what I get from that paragraph, but apparently you're stuck in an almost infinite loop unless you enter the actual value of EOF yourself using a keyboard combination.

    Is this what's supposed to happen? If so, what's the point of all the examples using EOF, when the authors don't remotely imply that the only way getchar() is going to return EOF is if you feed EOF to it? I thought it automatically returned it when it had no more characters to read from one text stream. The program above goes on to read countless text streams.


  2. #2
    Registered User
    Join Date
    May 2009
    You must understand, knowledge of how Unix like OS works is assumed in the examples given in the K&R C books.

    Most of these simple examples are designed to work with redirected input to the commands.

    command < input.txt
    Tim S.
    Last edited by stahta01; 11-12-2011 at 12:22 PM.

  3. #3
    Registered User
    Join Date
    Nov 2011
    Saratoga, California, USA
    Somewhere in that book, I'm sure it is explained that when reading from STDIN, you must send EOF signal. i.e. CTRL-C

  4. #4
    Registered User
    Join Date
    Jun 2005
    Quote Originally Posted by Tclausex View Post
    Somewhere in that book, I'm sure it is explained that when reading from STDIN, you must send EOF signal. i.e. CTRL-C
    CTRL-C is not the signal for end of file on any system that I know of.

    CTRL-C is, under a lot of systems, for aborting the program (the terminal driver generates a SIGINT signal under unix). That does not cause getchar() to return EOF.

    Under several flavour of Unix, CTRL-D causes the terminal driver to generate an EOT (end of transmission) signal, which will, in turn, cause an end of file to be detected on stdin. EOT also, often, causes buffered input to be dropped so, if the user doesn't want input to be lost, the user needs to hit the "Enter" key, before hitting CTRL-D. This behaviour of the terminal driver can be disabled by putting the terminal driver in "raw" mode (in which case, a CTRL-D character is seen in input, EOT is not generated, and end-of-file is not detected).

    Under MS-DOS (and subsequently, windows) the EOT character is CTRL-Z. Depending on configuration of the system, CTRL-Z has to be entered twice.

    Since, conceptually, stdin is an infinite-length stream, there is no guarantee that EOF can be detected on it. As stahta101 said, the way to be sure getchar() will eventually return EOF is to redirect input from a file (which has a defined end, so EOT will be generated). If you're using getchar() to receive keyboard input, you rely on the terminal driver generating EOT - otherwise getchar() will never return EOF, and will instead wait forever for input if there is none pending.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Misconception about classes?
    By cpudaman in forum C++ Programming
    Replies: 12
    Last Post: 01-02-2008, 01:41 AM
  2. Water and Electricity: Common Misconception
    By Liger86 in forum A Brief History of
    Replies: 15
    Last Post: 12-05-2003, 10:03 PM

Tags for this Thread