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

Question

作为一个小背景,我对C编程语言很陌生,因此一直试图完成第二版Kernighan&Ritchie手册中的一些练习.我确实意识到我可以通过更多地使用标准库来更简洁地处理某些问题,但是我试图尽可能地保持我的有用命令的所有内容与本书保持同步.

如果它有所不同,我正在使用Tiny C编译器(TCC)在Windows XP环境中编译我的源代码,并在XP控制台(cmd.exe)中执行二进制文件.

问题:处理End-of-File (EOF) characters.我已经整理了一个小测试用例来说明问题.该程序似乎处理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等待更多输入或在^ C/^ Z [enter]上正确结束)

样本输入2: abcd^Zefgh

示例输出2 :( Count: 4等待更多输入或在^ C/^ Z [enter]上正确结束)

如两个示例中所述,在启动^ C/^ Z [enter]序列之前不输出字符计数.在启动之前,程序会等待(并确实处理)更多输入.但是,如示例2中所述,当程序遇到初始^ Z时,如果启动^ C/^ Z [enter]序列,它将停止处理该输入行,等待更多输入或返回正确计数.

我无法弄清楚为什么程序只是部分处理EOF字符.在我看来,如果它截断样本2的末尾,它也应该完全脱离循环.任何想法为什么在识别EOF字符时程序不会立即打印当前计数并退出？

Answer 1

这个答案是unix-ish,但我认为在Windows上发生了类似的现象.EOF的基本形式是零长度read.在交互式输入设备(终端)上,有一种在输入流中具有EOF的特殊机制,但是如果已经有要读取的输入,它将与该输入一起被消耗(导致非零长度read),因此从不应用程序注意到了.只有当EOF发生且没有先前输入缓冲时,才能注意到应用程序并对其起作用.

如果您可以访问Linux(或其他*nix)系统,请编写类似的测试程序并在其下运行strace.观察read发生的基础调用,并且这种否则不直观的行为的原因将是有意义的.