編程中EOF問題

(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.