为什么需要多个 EOF (CTRL+Z) 字符？

Question

作为一点背景知识，我对 C 编程语言相当陌生，因此一直在尝试完成第二版 Kernighan & C 语言中的一些练习。里奇手册。我确实意识到，通过更多地利用标准库，我可能可以更简洁地处理某些问题，但我正在努力使我的有用命令库尽可能与本书保持同步。

如果有影响的话，我将使用 Tiny C 编译器 (TCC) 在 Windows XP 环境中编译源代码，并在 XP 控制台 (cmd.exe) 中执行二进制文件。

问题：处理文件结束 (EOF) 字符。我整理了一个小测试用例来说明这个问题。该程序似乎处理 EOF 字符（部分）。我将尝试用示例输入/输出来演示该问题。

#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;
}

示例输入 1：abcd^Z[enter]（其中 ^Z/CTRL+Z 代表 EOF 字符，[enter] 代表 Enter 键。）

示例输出 1：Count: 4< /code> （等待更多输入或在 ^C/^Z[enter] 上正确结束）

示例输入 2：abcd^Zefgh

示例输出 2：计数：4 (等待更多输入或在 ^C/^Z[enter] 上正确结束）

正如两个示例中所指出的，在启动 ^C/^Z[enter] 序列之前不会输出字符计数。在启动之前，程序会等待（实际上是处理）更多输入。但是，如示例 2 中所述，当程序遇到初始 ^Z 时，它会停止处理该输入行，等待更多输入，或者在启动 ^C/^Z[enter] 序列时返回正确的计数。

我不明白为什么程序只部分处理 EOF 字符。在我看来，如果它截断了示例 2 的末尾，那么它也应该完全脱离循环。有什么想法为什么在识别 EOF 字符后程序不会立即打印当前计数并退出？

Answer 1

这个答案是unix-ish，但我认为类似的现象也发生在Windows 上。 EOF 的基本形式是零长度读取。在交互式输入设备（终端）上，有一种特殊的机制可以在输入流中包含 EOF，但是如果已经有要读取的输入，它将与该输入一起被消耗（导致非零长度读取），因此从未被应用程序注意到。只有当 EOF 发生且没有缓冲先前的输入时，应用程序才能注意到并采取行动。

如果您可以访问 Linux（或其他 *nix）系统，请编写类似的测试程序并在 strace 下运行它。观察发生的底层 read 调用，就会明白这种不直观行为的原因。

Answer 2

这可以追溯到计算的石器时代。至少是 CP/M，早期的 DEC 操作系统可能会更久。 CP/M 不存储文件的大小，它只记录磁盘扇区的数量，每个扇区 128 字节。对于二进制文件来说这不是问题，程序在有足够的文件时就会停止读取。但对于文本文件来说肯定是一个问题。

因此按照惯例，文本文件的文件结尾标记为代码 0x1a、Control+Z。由于遗留下来的文本文件大于其中的文本量，因此必须在每一代连续的 CRT 实现中继承这一点。 Windows 对此并不关心，这纯粹是 CRT 实现细节。这就是为什么在控制台输入 Ctrl+Z 不会执行任何特殊操作。一旦按 Enter，cmd.exe 中的 CRT 就会再次调用旧行为并声明 EOF。

Answer 3

我不确定 TCC，但在相当多（大多数？）情况下，您需要或多或少地输入 ^Z 本身才能将其识别为 EOF（即，您需要一系列 [enter ]^z[输入]）。

Answer 4

当您键入 ^Z 时，Windows 不会自动生成 EOF；它只是从 DOS 继承下来的约定。 C 编译器的运行时必须识别它并设置 EOF 标志，我猜 Tiny C 不会这样做。

另一方面，^C 可以被 Windows 命令环境识别。它并不一定意味着EOF，我认为它更像是一个中止信号。

Answer 5

我猜想标准输入是行缓冲的（它在 Unix 上）。 DOS 有一些比 stdio 级别更低的 getch() 和 getche() 函数，因此它们绕过了 stdio 缓冲。我不知道如何在 Windows 上禁用输入缓冲，在 Unix 上可以通过将终端设置为非规范模式来完成。