macOS 和 centos 上的 EOF 不同的结果

Question

我正在使用EOF跳出'while'循环，并想通过'scanf'输入一些数字。循环外的'scanf'在macos上不起作用。

我试过在macos和centos上运行这段代码。centos上的结果就是我需要的。

#include <stdio.h>
#include <stdlib.h>
int main(){
 int i;
 //ctrl+d=EOF
 while(scanf("%d",&i) != EOF){
  printf("?");
 }
 printf("\nloopend\n");
 //those 'scanf' are ignored on macos.
 scanf("%d",&i);
 scanf(" %d",&i);
 scanf("%d ",&i);
 printf("\nend\n");
}

输入（不带'，'）： 1,\n,ctrl+d

输出（centos）：

1
?
loopend
//waiting for input here

输出（macos）：

1
?
loopend

end
//the program ended directly

Answer 1

MacOS 行为正确。根据C standard §7.21.7.1/3（fgetc库函数），文件结束指示是粘性的；一旦fgetc 看到 EOF，它必须设置文件的文件结束指示符，这将导致后续调用返回EOF，直到文件结束指示符被清除，例如clearerr()：

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

由于其他输入函数，包括scanf，应该像通过重复调用fgetc 来实现一样，因此EOF 也应该对它们具有粘性。如果您想在收到 EOF 返回后继续阅读，您应该在流上调用 clearerr()。 （或其他重置指标的东西，例如seek()。）

多年来，标准 C 库的 Gnu 实现并没有遵循标准。它只报告了一次 EOF，让下一个 fgetc 等待终端和管道等设备上的更多输入。 2006 年报告的错误是 finally fixed in v2.28，于 2018 年 8 月发布，尽管它可能还不是 Centos 发行版的一部分。

[注意：this answer 中对此行为进行了更长的讨论，包括现在已经过时的抱怨（我）和一些关于该问题的历史讨论的链接。]

无论如何，可移植代码应该调用clearerr() 一直很清楚，因为 BSD 派生的标准库实现（包括 MacOS）遵循上面引用的标准。