c - Why do I require multiple EOF (CTRL+Z) characters?

Question

As a little background, I am quite new to the C Programming Language and as such have been attempting to work through some of the exercises in the second edition of the Kernighan & Ritchie manual. I do realize that I could probably deal with certain issues more succinctly by utilizing the standard library more, but am trying to keep my repertoire of useful commands in sync with the book as much as possible.

If it makes a difference, I am compiling my source in a Windows XP environment using the Tiny C Compiler (TCC) and am executing the binaries within the XP Console (cmd.exe).

Problem: handling of End-of-File (EOF) characters. I've put together a small test case to illustrate the issue. The program seems to handle the EOF character (partially). I will try to demonstrate the issue with sample inputs/outputs.

#include <stdio.h>

int main() 
{
    int character, count;

    character = 0;
    character = getchar();

    for (count = 0; character != EOF; ++count) 
    {
        character = getchar();
    }

    printf("Count: %d", count);
    return 0;
}

Sample input 1: abcd^Z[enter] (where ^Z/CTRL+Z represents the EOF character and [enter] represents the Enter key.)

Sample output 1: Count: 4 (waits for more input or ends properly on ^C/^Z[enter])

Sample input 2: abcd^Zefgh

Sample output 2: Count: 4 (waits for more input or ends properly on ^C/^Z[enter])

As noted in both examples, the character count is not output until a ^C/^Z[enter] sequence is initiated. Until initiated, the program waits (and indeed processes) more input. However, as noted in example 2, when the program encounters the initial ^Z, it stops processing that line of input, waiting for more input or returning the correct count if a ^C/^Z[enter] sequence is initiated.

I can't figure out why the program is only partially handling the EOF character. Seems to me that if it is truncating the end of sample 2 that it should also be breaking out of the loop entirely. Any ideas why upon recognition of an EOF character the program doesn't immediately print the current count and exit?

Answer 1

This answer is unix-ish, but I think a similar phenonemon is happening on Windows. The underlying form of an EOF is a zero-length read. On interactive input devices (terminals), there is a special mechanism for having an EOF in the input stream, but if there's already input to be read, it will be consumed along with that input (resulting a non-zero length read) and thus never noticed by the application. Only when the EOF occurs with no prior input buffered can it be noticed and acted upon by the application.

If you have access to a Linux (or other *nix) system, write a similar test program and run it under strace. Watch the underlying read calls that happen, and the reason for this otherwise-unintuitive behavior will make sense.