なぜgetchar（）は行の先頭でのみEOFを認識しますか？

Question

この例では、K & R帳

#include<stdio.h> 


main() 
{ 
    long nc; 

    nc = 0; 
    while(getchar() != EOF) 
     ++nc; 
    printf("%ld\n", nc); 
} 

からで、それはそのように動作し、なぜあなたは私に説明してもらえます。ありがとう。 （それは、行の先頭にいない限り）

^Z^Zは、いずれかの

Answer 1

動作しないのtty EOFの従来のUNIXの解釈文字がバッファリングされているもの読んだ後read復帰を阻止するようにすることです調理されたttyラインバッファの内側にある。改行の開始時には、0（0バイトを読み取る）を返すreadを意味し、0-サイズのreadは、通常ファイルのファイルの終了を検出する方法です。

なぜ行の途中で最初EOFがちょうどCランタイムライブラリは、ファイルの終わりを検出することはない、readする行の先頭を強制しています。 2つのEOFの文字列は0サイズの読み取りを生成します。これは、アプリケーションによって空のバッファがreadに強制されるためです。

$ cat 
foo[press ^D]foo <=== after ^D, input printed back before EOL, despite cooked mode. No EOF detected 
foo[press ^D]foo[press ^D] <=== after first ^D, input printed back, and on second ^D, cat detects EOF 

$ cat 
Some first line<CR> <=== input 
Some first line <=== the line is read and printed 
[press ^D] <=== at line start, ^D forces 0-sized read to happen, cat detects EOF 

私はあなたのCランタイムライブラリは、セマンティクスが（Windows上で単独のシステムコールを、聞かせて、kernel32呼び出しのレベルで^Zの特別な取り扱いがありません）上記の模倣することを前提としています。そのため、入力行の途中であっても、おそらく^Z^Zの後にEOFを検出するのです。

Answer 2

プログラムはEOFを実際の入力の最後に読みます。あなたの端末/ OS /その他のファイルが、行の先頭で終わるファイルだけを許可すれば、そのファイルを見つけることができます。これは、データが一度に1行ずつしか送信されない旧式の端末へのスローバックだと私は信じている（私が知っているのは、それがパンチされたカードリーダーに戻るということだから）。

EOFの中間線で準備したファイルからデータを読み込みます。あなたは、編集者の中にはこれを難しくしていることさえあるかもしれません！あなたのプログラムはそれを入力としてうまく動作するはずです。

Answer 3

EOFは「ファイルの終わり」を示します。改行（Enterを押すとどうなるか）はファイルの終わりではなく、行の終わりなので、改行はこのループを終了しません。

オペレーティングシステムによっては、EOF文字は、行の最初の文字、つまりEnterの後の最初の文字の場合にのみ機能します。コンソール入力はしばしば行指向であるため、Enterをフォローアップするまで、システムはEOF文字を認識しないことがあります。

Answer 4

私はあなたと同じ質問をしました。機能getchar()を終了したい場合は、2 EOFを入力するか、<ENTER>にEOFを加えて入力する必要があります。

そして、ここだ、私はこの質問についての検索が容易な答え：

の端末に入力する文字がある場合は、EOFが入るの新しいターンを喚起なる、この入りを止めるような役割を果たします。 getchar（）が新しい入力を待っているとき（入力したばかりのEOFなど）、入力しようとしているEOFは「end」と等しいですこの関数はgetchar（）関数の実行を停止します。

PS：getchar()を使用しているときに質問が発生します。私はこの答えが理解しやすいと思うが、それは中国語から翻訳されているのであなたのためではないかもしれないと思う。