在另一個貼子中,我與一些朋友對 getc 展開了一些討論. 由于覺得樓主最終未能明白
我的意思,所以我把我個人的看法總結(jié)出來,寫在這里.我不太擅長說明,但已經(jīng)盡力了.
任何人轉(zhuǎn)本貼, 請務必把本人的名字寫在顯眼的位置.??


約定編譯器為 gcc2/x86:
所以 char, unsigned char 為 8 位, int 為 32 位


(1) 字節(jié)的讀取

在正常的情況下, getc 以 unsigned char 的方式讀取文件流, 擴張為一個整數(shù),并返
回. 換言之, getc 從文件流中取一個字節(jié), 并加上24個零,成為一個小于256的整數(shù),
然后返回.

int c;
while ((c = fgetc (rfp))!= -1) // -1就是 EOF
fputc (c, wfp);

上面 fputc 中的 c 雖然是整數(shù), 但在 fputc 將其寫入文件流之前, 又把整數(shù)的高24位
去掉了, 因此 fgetc, putc 配合能夠?qū)崿F(xiàn)文件復制. 到目前為止, 把 c 定義為
char仍然是可行的, 但下面我們將看到,把 c 定義為 int 是為正確判段文件是否結(jié)束.

(2) 判斷文件結(jié)束.

多數(shù)人認為文件中有一個EOF,用于表示文件的結(jié)尾. 但這個觀點實際上是錯誤的,在文
件所包含的數(shù)據(jù)中,并沒有什么文件結(jié)束符. 對getc 而言, 如果不能從文件中讀取,
則返回一個整數(shù) -1,這就是所謂的EOF. 返回 EOF 無非是出現(xiàn)了兩種情況,一是文件已
經(jīng)讀完; 二是文件讀取出錯,反正是讀不下去了.

請注意: 在正常讀取的情況下, 返回的整數(shù)均小于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, 暗中降為字節(jié), c = 0xFF
if (c != -1)? ? // 字符與整數(shù)比較? c 被帶符號(signed)擴展為0xFFFFFFFF, 喔噢,
條件成立,文件復制提前退出.

while ((c=fgetc(rfp))!=EOF) 中的判別條件成立, 文件復制結(jié)束! 意外中止.

(5) 將 c 定義為 unsigned char;

當讀到文件末尾, 返回 EOF 也就是 -1 時,

unsigned char c;
c = fgetc (rfp); // fgetc (rfp)的值為EOF,即-1,即0xFFFFFFFF, 降格為字節(jié), c=0xFF
if ( c!= -1)??// c 被擴展為 0x000000FF, 永遠不回等于 0xFFFFFFFF

所以這次雖然能正確復制 0xFF, 但卻不能判斷文件結(jié)束. 事實上,在 c 為 uchar 時,
c != -1 是永遠成立的, 一個高質(zhì)量的編譯器, 比如 gcc會在編譯時指出這一點.

(6) 為何需要feof?
FILE *fp;
fp 指向一個很復雜的數(shù)據(jù)結(jié)構(gòu), feof 是通過這個結(jié)構(gòu)中的標志來判斷文件是否結(jié)束的.
如果文件用 fgetc 讀取, 剛好把最后一個字符讀出時, fp 中的EOF標志不會打開,這時
用feof判斷,將會得到文件尚未結(jié)束的結(jié)論.

fgetc 返回 -1 時, 我們?nèi)詿o法確信文件已經(jīng)結(jié)束, 因為可能是讀取錯誤! 這時我們
需要 feof 和 ferror.