| 约定编译器为 gcc2/x86: 所以 char, unsigned char 为 8 位, int 为 32 位 请参考 http://bbs.chinaunix.net/forum/23/20031223/229236.html (1) 字节的读取 在正常的情况下, getc 以 unsigned char 的方式读取文件流, 扩张为一个整数,并返 回. 换言之, getc 从文件流中取一个字节, 并加上24个零,成为一个小于256的整数, 然后返回. int c; while ((c = fgetc (rfp))!= -1) // -1就是 EOF fputc (c, wfp); 上面 fputc 中的 c 虽然是整数, 但在 fputc 将其写入文件流之前, 又把整数的高24位 去掉了, 因此 fgetc, putc 配合能够实现文件复制. 到目前为止, 把 c 定义为 char仍然是可行的, 但下面我们将看到,把 c 定义为 int 是为正确判段文件是否结束.
(2) 判断文件结束. 多数人认为文件中有一个EOF,用于表示文件的结尾. 但这个观点实际上是错误的,在文 件所包含的数据中,并没有什么文件结束符. 对getc 而言, 如果不能从文件中读取, 则返回一个整数 -1,这就是所谓的EOF. 返回 EOF 无非是出现了两种情况,一是文件已 经读完; 二是文件读取出错,反正是读不下去了. 请注意: 在正常读取的情况下, 返回的整数均小于256, 即0x0~0xFF. 而读不出返回的 是 0xFFFFFFFF. 但, 假如你用fputc把 0xFFFFFFFF 往文件里头写, 高24位被屏蔽,写入的将 是 0xFF.
3) 0xFF 会使我们混淆吗? 不会, 前提是, 接收返回值的 c 要按原型定义为 int. 如果下一个读取的字符将为 0xFF, 则 int c; c = fgetc (rfp); // c = 0x000000FF; if (c != -1) // 当然不等, -1 是 0xFFFFFFFF fputc (wfp); // 噢, OXFF 复制成功. 字符0xFF, 其本身并不是EOF. (4) 将 c 定义 char 假定下一个读取的字符为 0xFF 则 char c; c = fgetc (rfp); // fgetc(rfp)的值为 0x000000FF, 暗中降为字节, c = 0xFF if (c != -1) // 字符与整数比较? c 被带符号(signed)扩展为0xFFFFFFFF, 喔噢, 条件成立,文件复制提前退出. while ((c=fgetc(rfp))!=EOF) 中的判别条件成立, 文件复制结束! 意外中止. (5) 将 c 定义为 unsigned char; 当读到文件末尾, 返回 EOF 也就是 -1 时, unsigned char c; c = fgetc (rfp); // fgetc (rfp)的值为EOF,即-1,即0xFFFFFFFF, 降格为字节, c=0xFF if ( c!= -1) // c 被扩展为 0x000000FF, 永远不回等于 0xFFFFFFFF 所以这次虽然能正确复制 0xFF, 但却不能判断文件结束. 事实上,在 c 为 uchar 时, c != -1 是永远成立的, 一个高质量的编译器, 比如 gcc会在编译时指出这一点. (6) 为何需要feof? FILE *fp; fp 指向一个很复杂的数据结构, feof 是通过这个结构中的标志来判断文件是否结束的. 如果文件用 fgetc 读取, 刚好把最后一个字符读出时, fp 中的EOF标志不会打开,这时 用feof判断,将会得到文件尚未结束的结论. fgetc 返回 -1 时, 我们仍无法确信文件已经结束, 因为可能是读取错误! 这时我们 需要 feof 和 ferror. |
