在另一個貼子中,我與一些朋友對 getc 展開了一些討論. 由于覺得樓主最終未能明白
我的意思,所以我把我個人的看法總結出來,寫在這里.我不太擅長說明,但已經盡力了.
任何人轉本貼, 請務必把本人的名字寫在顯眼的位置.
約定編譯器為 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. // lixforalpha 請注意這一點
(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.