刚学习C语言读取文件的时候,可能都遇到过这个“bug”,读到末尾时数据有重复。
解决方案也是五花八门,甚至有人把数据先缓存了,再忽略掉最后一组....
不妨看一段代码,两种解决方案,猜猜看,究竟哪一个方案是正确的。
曾经,我毫不犹豫的选择一,过了不久又毫不犹豫的选择二。然而,非常遗憾,没有
一个是正确的。暂不解释why,来一段MSDN上的代码,关于feof的一个example:
不要惊讶,你没看错,MSDN是先使用feof,然后再读取,跟网上的看法有些出入。
到底是为什么呢?
我觉得,还是从feof和fread的源码开始分析比较好,实现可能不同,用法应该是一致的。
以GLIBC 2.10的源码为例。不管是 unlocked 还是 非unlocked,feof最终还是调
用了unlocked的那个_IO_feof_unlocked“函数”,所以分析该“函数”即可。
现在可以得到一个结论:
- feof的返回值,仅仅取决于文件结构是否被打上 _IO_EOF_SEEN 标志。
feof本身并不影响这个标志,因此可以断定,标志是在读取的时候被修改的,于是
去追寻fread的源码。经历了宏的泥淖,欣赏了纯C填虚函数表模拟C++多态的壮
烈,终于找到了fread的背后黑手。fread实际上可能调用不同的函数,mmap文件
和普通文件的处理,是不一样的,不过知道其中一个便可,因为底层的差异,对程
序员是透明的,只要展示给程序员看的一面是一致的就OK。且看关键部分代码:
看到_IO_SYSREAD有什么感觉呢? 哦,你可以把它当成表现跟read系统调用一样
的东西,返回值大于0,就是实际读取字节数;等于0,就是文件之前已被读完(或者
是文件根本就是空的),本次没读到数据;小于0就是失败,有错误发生。
总结代码中的流程和细节,整理出来就是:
- 标准IO是带有缓存的,每一次请求,未必对应一次系统调用
- 缓存剩余字节数大于等于请求的,直接使用缓存,不产生系统调用
- fread当且仅当,系统调用读取到的字节数为0时,才会打上结束标志
- feof只检查_IO_EOF_SEEN标志位,不做其它影响返回值的判断
根据这些,不难得出以下结论:
- 文件全部读完,即使缓存用尽且SYS_READ读尽,feof未必返回真值
- SYS_READ实际读取到0字节的事情发生后,feof一定返回真值
- fread实际读取的字节数少于预期时,feof一定返回真值
- feof可以只检查标志就做出判断,而fread可能多一次系统调用才知道结束
- feof返回0的时候,上一次读取的数据,一定是有效数据
至此,已经不难理解,为什么最上面贴的两种方案都是错的。因为它们都没有对
fread的返回值做出反应,如果对这个返回值加以处理,无论是先读后判断还是先
判断后读取,都是没有问题的,都能得到正确的结果。当然,这得有个前提,就是
除了feof外,有别的方法判断是否结束,倘若如fgetc那般,读取的字符作为函数返
回值,读二进制文件时,就无法判断了,因为二进制文件本身也可能含有EOF字符。
这种情况,只有一种方案,就是先读取,再用feof判断是否结束。
做了那么长时间的铺垫,现在回到本文的核心。是先读取还是先判断?我认为:
- 在决定用哪一种方案前,首先要考虑用于读取的那个函数的返回值的意义
- 如果你不想了解细节,也不屑于些许性能,一律先读取后判断,肯定不会有错
- 如果读取函数的返回值蕴含是否读取成功,那么先判断后读取,可能更加高效
但是有一点,不管是哪种方式,如果用于读取的函数,返回值包含读取是否成功或者实际
读取字节数等信息,这个信息是一定要考虑的。同样,写入操作也好,其它操作也好,只
要函数带有返回值,且未注明这个返回值没有意义,都应该认真推敲下这个返回值的意义,
然后决定是否需要处理这个返回值。