为什么 POSIX API 没有文件结束功能？答案

【问题标题】：Why doesn't the POSIX API have an end-of-file function?为什么 POSIX API 没有文件结束功能？
【发布时间】：2012-01-14 03:24:33
【问题描述】：

在 POSIX API 中，read() 返回 0 表示已到达文件结尾。为什么没有单独的函数告诉您read() 将返回零——而不需要您实际调用read()？

询问原因：由于您必须调用read() 才能发现它会失败，这使得文件读取算法更加复杂，并且可能效率稍低，因为它们必须分配可能不需要的目标缓冲区。

我们可能想做什么......

while ( !eof )
   {
   allocate buffer
   read to buffer
   process buffer
   }

我们必须做的...

while ( true )
   {
   allocate buffer
   read to buffer
   if ( eof ) release buffer, break;
   process buffer
   }

此外，这种行为似乎会传播到更高级别的 API，例如 C 中的 fread() 和 feof() —— 并在如何正确使用 feof() 方面造成很多混乱：

【问题讨论】：

我见过的最有趣的答案（类似问题）：stackoverflow.com/a/5605161/86967。需要考虑类似的逻辑是否适用于 POSIX API。
输入流大小是缓冲区大小的精确倍数的情况通常很少见。因此，在典型场景下，流结束并不是特别有用。我不记得确切，但是当我问这个问题时，我可能一直在处理流由非常特定大小的数据包/块组成的情况（这也足够大以至于很重要） .

【解决方案1】：

要了解为什么会出现这种情况，请了解流结束本质上并不是永久性情况。一个文件的读指针可能在末尾，但如果后续写入操作追加了更多数据，则后续读取将成功。

示例：在 Linux 中，从控制台读取时，新行后跟 ^D 将导致 posix::read() 返回零（表示“文件结束”）。但是，如果程序没有终止，程序可以继续读取（假设输入了额外的行）。

由于流结束不是永久性情况，甚至没有 is_at_end() 函数（POSIX 没有）也许是有意义的。不幸的是，这确实给程序员（和/或包装库）带来了一些额外的负担，以优雅而有效地处理这种复杂性。

【讨论】：