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 Kern

Answer 1

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]).

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

Answer 3

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.

Answer 4

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.

Answer 5

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.