c - 为什么“while(!feof(file))”总是错误的？

Question

我最近在很多帖子中都看到有人试图读取这样的文件：

#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char **argv)
{
    char *path = "stdin";
    FILE *fp = argc > 1 ? fopen(path=argv[1], "r") : stdin;

    if( fp == NULL ) {
        perror(path);
        return EXIT_FAILURE;
    }

    while( !feof(fp) ) {  /* THIS IS WRONG */
        /* Read and process data from file… */
    }
    if( fclose(fp) != 0 ) {
        perror(path);
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

这个循环有什么问题？

Answer 1

我想提供一个抽象的高层视角。

并发性和同时性

I / O操作与环境交互。环境不是您的程序的一部分，也不在您的控制之下。该环境确实与您的程序“同时存在”。与所有并发事件一样，关于“当前状态”的问题也没有道理：在并发事件之间没有“同时性”的概念。状态的许多属性根本不会同时存在。

让我更精确地说：假设您想问“您是否有更多数据”。您可以询问并发容器或I / O系统。但是答案通常是不可行的，因此毫无意义。因此，如果容器说“是”，该怎么办？到您尝试读取时，它可能不再有数据。同样，如果答案为“否”，那么在您尝试阅读时，数据可能已经到达。结论是，根本没有像“我有数据”这样的属性，因为您无法对任何可能的答案做出有意义的举动。 （使用缓冲输入的情况要好一些，可以想象得到“是的，我有数据”可以构成某种保证，但是您仍然必须能够处理相反的情况。然后输出情况肯定和我描述的一样糟糕：您永远不知道该磁盘或网络缓冲区是否已满。）

因此，我们得出结论，询问一个I / O系统是否能够执行I / O操作是不可能的，实际上是不合理的。我们与之交互的唯一可能方式（就像与并发容器一样）是尝试操作并检查其成功还是失败。在与环境进行交互的那一刻，只有那时，您才能知道该交互是否确实可行，并且在这一点上，您必须致力于执行交互。 （如果需要，这是一个“同步点”。）

紧急行动

现在我们到EOF。 EOF是您从尝试的I / O操作获得的响应。这意味着您正在尝试读取或写入某些内容，但是这样做时您无法读取或写入任何数据，而是遇到了输入或输出的末尾。基本上对于所有I / O API都是如此，无论是C标准库，C ++ iostream还是其他库。只要I / O操作成功，您就根本无法知道将来的操作是否还会成功。您必须始终首先尝试该操作，然后响应成功或失败。

例子

在每个示例中，请仔细注意，我们首先尝试I / O操作，然后在有效时使用结果。还要注意，尽管每个示例中的结果采用不同的形状和形式，但我们始终必须使用I / O操作的结果。


C stdio，从文件中读取：

for (;;) {
    size_t n = fread(buf, 1, bufsize, infile);
    consume(buf, n);
    if (n < bufsize) { break; }
}

我们必须使用的结果是 n，即已读取的元素数（可能少至零）。
C stdio， scanf：

for (int a, b, c; scanf("%d %d %d", &a, &b, &c) == 3; ) {
    consume(a, b, c);
}

我们必须使用的结果是 scanf的返回值，即转换后的元素数。
C ++，iostreams格式化提取：

for (int n; std::cin >> n; ) {
    consume(n);
}

我们必须使用的结果是 std::cin本身，可以在布尔上下文中对其进行评估，并告诉我们流是否仍处于 good()状态。
C ++，iostreams getline：

for (std::string line; std::getline(std::cin, line); ) {
    consume(line);
}

和以前一样，我们必须使用的结果还是 std::cin。
POSIX， write(2)刷新缓冲区：

char const * p = buf;
ssize_t n = bufsize;
for (ssize_t k = bufsize; (k = write(fd, p, n)) > 0; p += k, n -= k) {}
if (n != 0) { /* error, failed to write complete buffer */ }

我们在这里使用的结果是 k，即写入的字节数。这里的要点是，我们只能知道在写操作之后写了多少字节。
POSIX getline()

char *buffer = NULL;
size_t bufsiz = 0;
ssize_t nbytes;
while ((nbytes = getline(&buffer, &bufsiz, fp)) != -1)
{
    /* Use nbytes of data in buffer */
}
free(buffer);

我们必须使用的结果是 nbytes，直到并包括换行符的字节数（如果文件未以换行符结尾，则为EOF）。

请注意，当发生错误或到达EOF时，该函数显式返回 -1（而不是EOF！）。


您可能会注意到，我们很少拼出实际的单词“ EOF”。我们通常会以其他方式检测到错误情况，这对我们来说更有意义（例如，无法执行所需的I / O）。在每个示例中，都有一些API功能可以明确告诉我们已经遇到了EOF状态，但是实际上这并不是一条非常有用的信息。它比我们经常关心的细节更多。重要的是I / O是否成功，而不是失败如何。


最后一个实际查询EOF状态的示例：假设您有一个字符串，并且想要测试它是否完整地表示一个整数，除了空格，末尾没有多余的位。使用C ++ iostream，它是这样的：

std::string input = "   123   ";   // example

std::istringstream iss(input);
int value;
if (iss >> value >> std::ws && iss.get() == EOF) {
    consume(value);
} else {
    // error, "input" is not parsable as an integer
}

我们在这里使用两个结果。第一个是 iss（流对象本身），以检查是否成功格式化了对 value的提取。但是，在又消耗了空格之后，我们执行了另一个I / O /操作 iss.get()，并期望它作为EOF失败，如果整个字符串已经被格式化提取所消耗，情况就是如此。

在C标准库中，您可以通过检查结束指针是否到达输入字符串的末尾来实现与 strto*l函数相似的功能。


答案

while(!eof)是错误的，因为它测试不相关的内容并且无法测试您需要知道的内容。结果是您错误地执行了假定代码正在访问已成功读取的数据的代码，而实际上却从未发生过。