对C语言的写文件操作fwrite的一个初学者常见误解
当初对C语言的 写文件操作 到底会有什么样的结果很困惑,今天读CSAPP的时候又把这段回忆勾起来了。以下,希望能对如当年我一样的同学们理解fwrite有点帮助。
1.题外话,文件的重要意义
教科书中一般都会提到C语言的文件有这么个特色,它把所有设备都看成相同的东西,并称这是个优势。有的同学可能会奇怪,这有什么可提的。这种优点是教科书的作者和教师们从更早的书里抄来的,更早的书是对当时的情况发表的看法。在UNIX系统和C语言以前,操作系统处于一个更萌芽和早期的状态,对不同的设备的操作都使用专门方法--你可以理解为各有单独的函数。试想,键盘、鼠标、显示器、打印机、磁带、磁盘、磁鼓,所有这些东西都要作读写操作,而读写操作从人类的视角看来如此之像,却使用全然不同的函数和参数。UNIX和C语言改变了这一点,它把所有的设备"抽象"为文件,对所有设备的操作,都用相同的一组函数,即文件读写,来完成。这些各种各样的文件当中,也包括目录,所以目录也是一种文件。网络socket也是一种文件,进程间通信,也是一种文件。当很多不同的东西都统一于文件的时候,它们的个性就抹杀掉了,容易管理和控制多了。
因为吾生也晚,咱们已经习惯于这个格局了,就认为用文件管理所有的东西是天经地义的事情了,所以难以感觉到诸侯割据各自为政时的不方便。
2.问题
当我们读文件的时候,事情相对简单。打开,然后读,然后关闭。我们读到的正是我们期待读到的东西。当我们写文件的时候,情况就不同了。
常见出现的错误是,我们可以有个文件,内容是:
abcdefghijlmn
我们的C代码是:
打开文件, (可能在中间某个位置) 写操作,关闭文件。
执行完C程序以后,我们发现文件的内容不是我们期待的结果。我们原本期待中间某处变成我们修改以后的样,比如:
abcAAfghijlmn。
但是文件的内容却变成了:
^@^@^@AA
3. 原因
造成上面的问题,其原因肯定不是"因为微软的编译器太垃圾了",而是我们没有仔细阅读手册。
我们错误地假想,C语言操作文件流 (流,也是个UNIX语境下的重要概念),就像操作内存里的数组一样,找开文件就是找到数组的头 (起始位置),写操作就是改变数组中某处的元素。
但是事情并不是这样。世界并非如此简单。把文件作为流操作,那是文件打开以后的事情,在文件打开的时候,非常重要地,程序员必须指出,准备创建或打开一个什么样的流。
手册 (man fopen) 说:
fopen的第一个参数是文件名,第二个参数需要我们注意。第二个参数称为 mode,我们可以理解为创造的流的"模式"。
其中对"w"这种模式的解释的第一句是:
"Truncate file to zero length or create text file for writing."
truncate的意思是"截断"。上述这句可以译为:把文件截断为0长度,或者创造用于写操作的文本文件。这里插一句,在UNIX/POSIX系统下,文本文件与二进制文件没有区别。所以,"w"模式所创造的流是,要么如果原来这个名字的文件已经存在,把它截断为0字节,无论里面有什么内容;要么如果原来没有这个文件,创造一个新的文件。
前面问题一节里的文件,原本是:
abcdefghijlmn
我们期待:
abcAAfghijlmn
但是却变成了:
^@^@^@AA
1.AA以后的东西会丢失,就是因为原来的文件被trancate到了0长度. 2."^@"是单独一个字符,即'