C语言标准IO： [先读再feof] VS [先feof再读]

刚学习C语言读取文件的时候，可能都遇到过这个“bug”，读到末尾时数据有重复。
解决方案也是五花八门，甚至有人把数据先缓存了，再忽略掉最后一组....

不妨看一段代码，两种解决方案，猜猜看，究竟哪一个方案是正确的。
/* *方案一：先判断，后读取 */ while (!feof(fp)) { fread(buf, 1, 100, fp); //do_some_thing } /* *方案二：先读取，后判断 */ while (1) { fread(buf, 1, 100, fp); if (feof(fp)) break; //do_some_thing }

曾经，我毫不犹豫的选择一，过了不久又毫不犹豫的选择二。然而，非常遗憾，没有
一个是正确的。暂不解释why，来一段MSDN上的代码，关于feof的一个example：

#include <stdio.h> #include <stdlib.h> int main( void ) { int count, total = 0; char buffer[100]; FILE *stream; fopen_s( &stream, "crt_feof.txt", "r" ); if( stream == NULL ) exit( 1 ); // Cycle until end of file reached: while( !feof( stream ) ) { // Attempt to read in 100 bytes: count = fread( buffer, sizeof( char ), 100, stream ); if( ferror( stream ) ) { perror( "Read error" ); break; } // Total up actual bytes read total += count; } printf( "Number of bytes read = %d/n", total ); fclose( stream ); }

不要惊讶，你没看错，MSDN是先使用feof，然后再读取，跟网上的看法有些出入。

到底是为什么呢?
我觉得，还是从feof和fread的源码开始分析比较好，实现可能不同，用法应该是一致的。
以GLIBC 2.10的源码为例。不管是 unlocked 还是 非unlocked，feof最终还是调
用了unlocked的那个_IO_feof_unlocked“函数”，所以分析该“函数”即可。
#define _IO_feof_unlocked(__fp) (((__fp)->_flags & _IO_EOF_SEEN) != 0)

现在可以得到一个结论：

• feof的返回值，仅仅取决于文件结构是否被打上 _IO_EOF_SEEN 标志。

feof本身并不影响这个标志，因此可以断定，标志是在读取的时候被修改的，于是
去追寻fread的源码。经历了宏的泥淖，欣赏了纯C填虚函数表模拟C++多态的壮
烈，终于找到了fread的背后黑手。fread实际上可能调用不同的函数，mmap文件
和普通文件的处理，是不一样的，不过知道其中一个便可，因为底层的差异，对程
序员是透明的，只要展示给程序员看的一面是一致的就OK。且看关键部分代码：
count = _IO_SYSREAD (fp, s, count); if (count <= 0) { if (count == 0) fp->_flags |= _IO_EOF_SEEN; else fp->_flags |= _IO_ERR_SEEN; break; }

看到_IO_SYSREAD有什么感觉呢? 哦，你可以把它当成表现跟read系统调用一样
的东西，返回值大于0，就是实际读取字节数；等于0，就是文件之前已被读完(或者
是文件根本就是空的)，本次没读到数据；小于0就是失败，有错误发生。

总结代码中的流程和细节，整理出来就是：

1. 标准IO是带有缓存的，每一次请求，未必对应一次系统调用
2. 缓存剩余字节数大于等于请求的，直接使用缓存，不产生系统调用
3. fread当且仅当，系统调用读取到的字节数为0时，才会打上结束标志
4. feof只检查_IO_EOF_SEEN标志位，不做其它影响返回值的判断

根据这些，不难得出以下结论：

1. 文件全部读完，即使缓存用尽且SYS_READ读尽，feof未必返回真值
2. SYS_READ实际读取到0字节的事情发生后，feof一定返回真值
3. fread实际读取的字节数少于预期时，feof一定返回真值
4. feof可以只检查标志就做出判断，而fread可能多一次系统调用才知道结束
5. feof返回0的时候，上一次读取的数据，一定是有效数据
   

至此，已经不难理解，为什么最上面贴的两种方案都是错的。因为它们都没有对
fread的返回值做出反应，如果对这个返回值加以处理，无论是先读后判断还是先
判断后读取，都是没有问题的，都能得到正确的结果。当然，这得有个前提，就是
除了feof外，有别的方法判断是否结束，倘若如fgetc那般，读取的字符作为函数返
回值，读二进制文件时，就无法判断了，因为二进制文件本身也可能含有EOF字符。
这种情况，只有一种方案，就是先读取，再用feof判断是否结束。

做了那么长时间的铺垫，现在回到本文的核心。是先读取还是先判断？我认为：

• 在决定用哪一种方案前，首先要考虑用于读取的那个函数的返回值的意义
• 如果你不想了解细节，也不屑于些许性能，一律先读取后判断，肯定不会有错
• 如果读取函数的返回值蕴含是否读取成功，那么先判断后读取，可能更加高效

但是有一点，不管是哪种方式，如果用于读取的函数，返回值包含读取是否成功或者实际
读取字节数等信息，这个信息是一定要考虑的。同样，写入操作也好，其它操作也好，只
要函数带有返回值，且未注明这个返回值没有意义，都应该认真推敲下这个返回值的意义，
然后决定是否需要处理这个返回值。