寫個小程序測試一下，就明白a模式有什麼陷阱了。

#include <stdio.h>

int main(void)
{
    FILE* file = fopen("test.txt", "a+");
    fputs("check!", file);
    fputc(EOF, file);
    fclose(file);

    return 0;
}

下面是把上面代碼程序反覆運行3次的結果：


看不明白9樓的，結合這個測試結果，就明白了。

[ 本帖最后由 TonyDeng 于 2015-8-12 11:21 编辑 ]

12楼的运行结果表明：同一篇文档，被写进了3个文件结束符EOF，但文件的实际长度是3份，若在读的时候用遇到EOF的方法来判断文件结束，则必然是错的。这个结果也表明，对a模式文件来说，资料所言“不会挪动EOF”是真的，即在追加数据的时候，是机械地从文件的最后一个字节（这个最后显然是从文件系统记录的文件长度而来）的后面追加，根本不判断最后一个字符是不是EOF。如果问题到此为止，那么还好处理，但问题是真实的情形，不是所有文档都是有EOF结束符的。这也就是说，要写出普遍能用的a模式读写文件代码，必须在判断文件结束处有一段if()语句，你无法省掉它。

再看另一个暗坎：我输出每一段数据，"check!"是6个字符（显然'\0'没有输出），然后加了1个EOF字符，总共7个，程序反覆运行3次，共计21个字节，这在文件管理器的属性中可以看到，文件的长度的确是21Byte。然而问题来了，按EOF的意义，犹如字符串的'\0'，是不应被计算的，文件的有效长度应是18，确实，如果程序祗运行一次，我们心目中就是按输出了6字节考虑的，本来不输出EOF，也没问题，那时文件的长度就是6。这样的暗坎，会被精确计算带来隐患，尤其那些用位置定位的代码，稍有不慎，就栽在这种地方。

写程序，不是遇到过千奇百怪的问题，有应付的经验，想当然是不行的。很多人追求代码简单，以为代码量越少越好，殊不知那些代码未必可以应付现实问题，如果抱着那样的观念编程，质量必然很成问题。我以前听一个高人说过，其实不管用任何语言，只要程序写到成熟，最终的效率都是差别不大的，最典型的一个例子居然有人用解释BASIC写的程序效率超越用C写的，这话随着我实践的经历，越来越觉得是真理。