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?

As an update, I have determined that the Tiny C Compiler does appear to recognized the EOF character ^Z. Both ^Z (input) and EOF (Symbolic Constant) are recognized as the value -1. — bfisher, Apr 13 '11 at 22:23
Another update, I defined another symbolic constant EOT (End-of-Transmission) to be 4. Now when I test against this constant, by issuing a ^D (recognized to be the value 4), all works according to plan. However, if EOT is defined be -1, as EOF, the program breaks again. This does seem odd, since ^Z is being recognized by the program to be the value -1. — bfisher, Apr 14 '11 at 00:25
You're mistaken to look at `^Z` as a character. Whichever character at the terminal/console level is designated to generate EOF is interpreted by another layer before it reaches your application. On Windows, `^D` is not special by default, so you just get the byte `^D` (4). — R.. GitHub STOP HELPING ICE, Apr 15 '11 at 11:27
@R.. Yep, I believe you're right. After having pondered the issue further, I've come to the conclusion that ^Z is recognized to be -1 when read by itself (probably because cmd truncates further input, resulting in a zero-length read). I'm only guessing here, but this makes sense when considering scenario 2 as the program reads only 'abcd' while waiting for further input. Seems that ^Z (unlike ^D which actually represents the ASCII character 4) is merely a symbolic representation for nothingness/void. Once again, thank you for your insight. You've definitely helped solidify this concept for me. — bfisher, Apr 15 '11 at 14:12

score 7 · Accepted Answer · answered Apr 14 '11 at 00:19

7

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.

answered Apr 14 '11 at 00:19

R.. GitHub STOP HELPING ICE

208,859
35
376
711

The info is much appreciated. I don't have a *nix machine running at the moment, but will have to set one up in the next few days for the sole purpose of testing this hypothesis. However, if the EOF signal is being consumed as suggested, I'm wondering why the program doesn't continue along happily reading whatever is left on the line (unless perhaps cmd is truncating after ^Z before the program ever gets that far.) – bfisher Apr 14 '11 at 00:31
That's probably a peculiarity of Windows I'm not familiar with. :-) – R.. GitHub STOP HELPING ICE Apr 14 '11 at 01:19

score 3 · Answer 2 · answered May 08 '11 at 15:13

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.

score 0 · Answer 3 · answered Apr 13 '11 at 20:34

0

I don't know for sure with TCC, but in quite a few (most?) cases, you need to enter the ^Z more or less by itself for it to be recognized as EOF (i.e., you need a sequence of [enter]^z[enter]).

answered Apr 13 '11 at 20:34

Jerry Coffin

476,176
80
629
1,111

score 0 · Answer 4 · answered Apr 13 '11 at 20:41

0

EOF is not generated by Windows automatically when you type ^Z; it's just a convention carried over from DOS. The runtime of your C compiler must recognize it and set the EOF flag, and I'm guessing Tiny C doesn't do that.

^C on the other hand is recognized by the Windows command environment. It doesn't necessarily mean EOF, I think it's more of an abort signal.

answered Apr 13 '11 at 20:41

Mark Ransom

299,747
42
398
622

Yep, ^C/CTRL+C sends a SIGINT signal or something that causes the currently running process to exit (which is why it works regardless). However, I still don't really understand why abcd^Zefgh only counts abcd if the EOF character isn't being processed. And then if it is, why the program continues looping and gathering input thereafter. – bfisher Apr 13 '11 at 20:55
@bfisher, I think it's premature to accept this answer - I didn't fully answer the question, did I? – Mark Ransom Apr 13 '11 at 21:50

score 0 · Answer 5 · answered May 08 '11 at 16:22

I'd guess standard input is line-buffered (it is on Unix). DOS had some getch() and getche() functions that are lower-level than stdio, so they bypass stdio buffering. I don't know how to disable input buffering on Windows, on Unix it's done by setting the terminal to non-canonical mode.

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

5 Answers5

Linked

Related