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

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?

Solution 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.

Solution 2:

This goes back to the stone-age of computing. At least CP/M, possibly longer back with early DEC operating systems. CP/M didn't store the size of a file, it only kept track of the number of disk sectors, 128 bytes each. Not a problem for binary files, a program simply stops reading when it has enough. But certainly a problem for text files.

So by convention, the end-of-file of a text file was marked with code 0x1a, Control+Z. Saddled with a legacy of text files that were larger than the amount of text in them, this had to be carried over in each successive generation of CRT implementations. Windows doesn't give a hoot about it, this is purely a CRT implementation detail. Which is why typing Ctrl+Z at the console doesn't do anything special. Once you press Enter, the CRT in cmd.exe invokes legacy behavior again and declares EOF.