为什么 fread 循环需要额外的 Ctrl+D 来用 glibc 发出 EOF 信号？

Question

通常，要向附加到 Linux 终端上的标准输入的程序指示 EOF，如果我只是按 Enter，则需要按一次 Ctrl+D，否则需要按两次。不过，我注意到patch 命令是不同的。有了它，如果我只是按 Enter，我需要按 Ctrl+D 两次，否则需要按 3 次。 （而不是cat | patch 没有这种奇怪之处。此外，如果我在输入任何实际输入之前按 Ctrl+D，它就没有这种奇怪之处。）深入研究patch 的源代码，我追踪这回the way it loops on fread。这是一个做同样事情的最小程序：

#include <stdio.h>

int main(void) {
    char buf[4096];
    size_t charsread;
    while((charsread = fread(buf, 1, sizeof(buf), stdin)) != 0) {
        printf("Read %zu bytes. EOF: %d. Error: %d.\n", charsread, feof(stdin), ferror(stdin));
    }
    printf("Read zero bytes. EOF: %d. Error: %d. Exiting.\n", feof(stdin), ferror(stdin));
    return 0;
}

当完全按原样编译和运行上述程序时，以下是事件时间线：

1. 我的程序调用fread。
2. fread 调用read 系统调用。
3. 我输入“asdf”。
4. 我按 Enter。
5. read 系统调用返回 5。
6. fread 再次调用read 系统调用。
7. 我按 Ctrl+D。
8. read 系统调用返回 0。
9. fread 返回 5。
10. 我的程序打印Read 5 bytes. EOF: 1. Error: 0.
11. 我的程序再次调用fread。
12. fread 调用read 系统调用。
13. 我再次按 Ctrl+D。
14. read 系统调用返回 0。
15. fread 返回 0。
16. 我的程序打印Read zero bytes. EOF: 1. Error: 0. Exiting.

为什么这种读取标准输入的方式会有这种行为，不像其他程序似乎读取它的方式？这是patch 中的错误吗？这种循环应该怎么写才能避免这种行为呢？

更新：这似乎与 libc 有关。我最初在 Ubuntu 16.04 的 glibc 2.23-0ubuntu3 上体验过它。 @Barmar 在 cmets 中指出它不会在 macOS 上发生。听到这个后，我尝试针对同样来自 Ubuntu 16.04 的 musl 1.1.9-1 编译相同的程序，但没有出现这个问题。在 musl 上，事件序列删除了第 12 步到第 14 步，这就是为什么它没有问题，但在其他方面是相同的（除了 readv 代替 read 的不相关细节）。

现在，问题变成了：glibc 的行为是错误的，还是 patch 错误地假设它的 libc 不会有这种行为？

Answer 1

我已经设法确认这是由于 2.28 之前的 glibc 版本中存在明确的错误（提交 2cc7bad）。相关引用来自the C standard：

字节输入/输出函数——本小节中描述的那些执行 输入/输出：[...]，fread

字节输入函数从流中读取字符，就好像连续 调用fgetc 函数。

如果设置了流的文件结束指示符，或如果流处于文件结束位置，则设置流的文件结束指示符并且fgetc 函数返回 EOF。否则，fgetc 函数从stream 指向的输入流中返回下一个字符。

（强调“或”我的）

下面的程序用fgetc演示了这个错误：

#include <stdio.h>

int main(void) {
    while(fgetc(stdin) != EOF) {
        puts("Read and discarded a character from stdin");
    }
    puts("fgetc(stdin) returned EOF");
    if(!feof(stdin)) {
        /* Included only for completeness. Doesn't occur in my testing. */
        puts("Standard violation! After fgetc returned EOF, the end-of-file indicator wasn't set");
        return 1;
    }
    if(fgetc(stdin) != EOF) {
        /* This happens with glibc in my testing. */
        puts("Standard violation! When fgetc was called with the end-of-file indicator set, it didn't return EOF");
        return 1;
    }
    /* This happens with musl in my testing. */
    puts("No standard violation detected");
    return 0;
}

为了演示错误：

1. 编译程序并执行
2. 按 Ctrl+D
3. 按 Enter 键

确切的错误是，如果设置了文件尾流指示符，但流不在文件尾，glibc 的 fgetc 将返回流中的下一个字符，而不是标准要求的 EOF .

由于fread是根据fgetc定义的，这就是我最初看到的原因。它之前被报告为 glibc bug #1190，并且自 2018 年 2 月提交 2cc7bad 以来一直被修复，该提交于 2018 年 8 月登陆 glibc 2.28。