控制檯輸入的怪現象，以C程序

我乳寧使用Visual Studio 2010的目的是爲了看看我定義變量c作爲char或int會發生什麼，因爲getchar()函數返回一個整數（以下簡單程序在C編程語言中廣爲人知的陷阱，請參閱int c = getchar()?）。控制檯輸入的怪現象，以C程序

#include <stdio.h> 

int main() 

{ 
    char c; 
    //int c; 

    while((c = getchar()) != EOF) 

     putchar(c); 

    printf("%d\n",c); 
    return 0; 
}

當我從控制檯輸入一些字符到這個程序時，我發現了一個奇怪的現象，如下圖所示。如果作爲輸入的EOF遵循字符序列（第1行），則無法正確識別（小右箭頭是輸出，第2行）。但是，如果是獨立輸入（第4行），則可以正確識別並終止程序。

我沒有在Linux上測試這個程序，但有人可以解釋爲什麼會發生這種情況嗎？

enter image description here

來源

2013-07-11 Bloodmoon

這種行爲與'c'聲明爲'int'時有什麼不同嗎？ –

@larsmans不，不是。如果'c'是'int'類型，我得到了相同的結果。 – Bloodmoon

嘗試輸入ÿ（y變音符號，帶有DIAERESIS的LATIN小字母Y，U + 00FF）;當你使用'char c;'時，我希望你的程序在讀取那個字符時也停止了，它不應該這樣做。如果你使用了'int c;'，你會沒事的。記住：'getchar（）'返回一個'int'！ –

你描述的是，基本上，終端的設計途徑是什麼。

你需要記住的是，EOF不是一個字符。當你輸入「ABCDEF CTRL-Z」，你正在進入八個輸入字符：一個，乙，Ç，d，ē，˚F，CTRL-Z，和返回。關於CTRL-Z（或在Unix/Linux上的CTRL-D）的唯一特別之處在於，如果您將它作爲新行中的第一項輸入，則不必輸入字符，終端的行爲就像已達到輸入文件的末尾。 getchar()函數將返回EOF。由於可裝配到unsigned char任何可能的值是用於getchar()一個有效的返回值，EOF可由於是負的，這就是爲什麼getchar()和家族被定義爲返回int是來自任何有效的返回值區別開來。

來源

2013-07-11 15:30:56

感謝您的回答，但它仍然無法解釋爲什麼'EOF'在某些字符後面沒有被正確識別，即不是在獨立行中。 – Bloodmoon

因爲這就是它的設計方式。當您按下用於發送EOF信號的鍵（Control-Z，Control-D或任何其他設備）時，它只被視爲在行首的EOF信號。從根本上說，它是這樣工作的，因爲它的設計是以這種方式工作的，這就是它。是的，你也會在Unix上看到同樣的行爲。 –

我明白了，謝謝！很奇怪，我沒有讀任何書，告訴我「EOF」應該是獨立的。 – Bloodmoon

如果你改變你的計劃一點點，放兩個printf語句，你會看到，這個程序實際上可以讀取CRTL + Z組合正確（ASCII代碼26）：

#include <stdio.h> 

int main() 

{ 
    char c; 
    //int c; 

    while((c = getchar()) != EOF) { 
     printf("%d\n",c); 
     putchar(c); 
     printf("\n"); 
    } 

    printf("%d\n",c); 
    return 0; 
}

但由於上述答案告訴，它必須在它自己的路線上;以便被正確解釋。因爲在窗口中，除了最後一行，每行都有一個EOL字符。最後一行之後有一個EOF字符。

來源

2013-07-11 15:33:11 gst

嗯，我感到困惑。事實上，在dubug模式下，我看到'c'的值是26，但我認爲這是不正確識別'EOF'的結果。我希望在'EOF'輸入時'c'爲'-1'，因爲默認情況下'c'是VS 2010中的'signed char'（我也相信gcc），這就是爲什麼最多的原因如果輸入的字符都是英文字符，將'c'定義爲'char'的時間不會導致錯誤。 – Bloodmoon

而且，你能解釋一下關於'EOL'嗎？ – Bloodmoon

根據ASCII表的CTRL + Z的實際值是26，並且在c中具有該值是正確的行爲。看一下這個頁面：http://rabbit.eng.miami.edu/class/een218/getchar.html – gst

控制檯輸入的怪現象，以C程序

回答

相關問題