YAFFS的一点小BUG

gogolinux

这几天工作中被发现调用FWRITE和WRITE都存在同样一个问题，就是写512字节没有问题，但是总数在超过512字节以后，没重新启动以前都是正常的，但是重启以后就会丢失一点或者多出一些，文件变成有规律的以K为单位的大小。
刚开始找了很多原因，第一找编译器的问题，换了好多个版本，结果都一样。后来开始找内核配置的问题，是不是CACHE引起的，但是这个CACHE内核配置也没找到，再后来发现一些可以设置和关闭对应FILE指针的函数，比如setbuffer setbuf 等，强行把cache内容写入的函数fflush，最后setbuffer这个函数设置一个自定义的缓冲可以解决问题，但是缓冲大小要在128-》512个字节之间，但是这样总不是办法，使用起来不方便，关键心里有个疙瘩在。。。
今天早上咬咬牙，直接找yaffs文件系统的原因，刚开始总是抱着查查看的态度，因为毕竟这个东西经过很多人验证应该不会出啥问题，至少我现在碰的情况也只是大家经常用的，要有这样的问题，大家可能早就发现了。
凭着直觉。。。找到yaffs_nand.c 从这里入手查问题，这个文件比较小，一看就知道应该从yaffs_WriteChunkWithTagsToNAND这个函数入手查，通过打印信息知道，果然这个函数是写文件的时候调用的，好，找到了线索了哦。。根据这个顺藤摸瓜找到了yaffs_guts.c中的yaffs_WriteDataToFile这个函数，最后问题就出在这里
   nToWriteBack =
       (nBytesRead >
        (start + n)) ? nBytesRead : (start + n);
通过打印信息可以知道nBytesRead =-1024  (start + n)=4( 和测试函数有关系 )
那nToWriteBack 应该是等于 start+n ，但是不是，结果等于 nBytesRead ,导致超出的512的部分没能正常写入，文件就变的很奇怪。
为什么引起的呢，n、nBytesRead 是int 的，而start 是 unsigned int 的，这样比较出错。
   nToWriteBack =
       (nBytesRead >
        (int)(start + n)) ? nBytesRead : (start + n);
这就正确了。

原因很明显，不同类型的数据比较的时候出现的错误结果，不同版本的编译器之间存在差异，本来这句话语法上不严谨应该说是错误的，有的编译器是能编译出预期的效果，而又的编译器可能就理解错误了，导致现在的结果。所以以后在写代码的时候特别要注意这些微小的细节，可能在你现在用的编译器下是很正常，当你移植或者升级编译器的时候可能就出现不同的结果，到那时候找问题就很头疼了。
写代码：优秀思路、简单语法、少玩技巧



本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/72877/showart_1712259.html