EOFについて教えてください

'\r'がで0000 1010 で表現されるように
EOF にも対応するバイナリがあるのでしょうか。

行動規範の内容に同意します

回答5件

CP/MやMS-DOSでは、0001 1010 (Ctrl+Z) が用いられました。これらのオペレーティングシステム (MS-DOSではバージョン2.xまで) では、ファイルサイズをディスクのセクタ長 (128バイト) の倍数にしかできなかったので、内容がバイト単位の任意の長さで終わってしまうテキストデータの場合には「この直前でデータは終わり」という標識になるコードが必要だったのです。

Unix系では、0000 0100 (Ctrl+D) が、コンソールからの入力の終了として処理されます。これはシェルの機能で入力が終了させられるというだけで、実際にこのコードがプロセスに入力されるわけではありません。このコードは制御文字としてはend of transmission (伝送終了) を表すので、一応使い途としては正しそうです。

C標準関数のgetc(3)などは、入力終端に達したときにEOFというシンボルで定義される定数を返します。コンパイラが対応する環境で実際にファイルの終端を表すコードが存在するかどうかとは関係なく、そういう動作をしますし、EOFの定義値は符号付き整数の-1といった、ファイル中のバイトとしてはありえない値です。

回答後追記。ご質問にあるコードですが

"\r"は0000 1101です。"\n"が0000 1010です。

投稿2016/10/18 13:00

編集2016/10/18 13:20

ikedas

総合スコア4443

hoge_yama

2016/10/19 10:49

CRは0x0dで0000 1101でした、ご指摘ありがとうございます。 C言語でもEOFがでてくるけど、関係あるのだろうかと思っておりましたが、違い(概念の階層)が違うことがはっきりしました。ご回答ありがとうございました。

行動規範の内容に同意します

具体的なコードはCP/Mの場合0x1a（ASCII制御文字のSUB）だったが、処理系により異なる。CP/Mの影響を受けたシステムでは、これを付ける慣習が長く続いたが、ファイルサイズから終端がわかるシステムでは付けないことが多い。

https://ja.wikipedia.org/wiki/End_Of_File

何らかのプログラムがデータを１バイトずつ読んでいるときに、『こいつ（この１バイト）が現れたらファイルの終わりということにしよう』という決め事ですので、今となっては『使っているソフトによって異なる」ということだと思います。

Linux/UNIX でたとえば cat[Enter] で標準入力を待っている状態だと、Ctrl+d(0x04) の入力で EOF とみなしてコマンドを抜けたり、といった部分で残ってはいますが、今となってはほとんど気にしなくてもよいのではないでしょうか。

投稿2016/10/18 12:54

hotta

総合スコア1615

hoge_yama

2016/10/19 10:54

なんらかの規格やルールでEOFなる『こいつ(この1バイト)が現れたらファイルの終わりということにしよう』というバイトがあるのか、ないのかが気になっていることでした。 EOFはファイルの終端をひとつ抽象化した概念(?)で具体的なバイトとは今では結びついていないということなんですね。ご回答ありがとうございました。

行動規範の内容に同意します

テキストファイルの終端として過去に0x1Aが使われていましたが、MS-DOSやCP/M時代の名残で最近のテキストファイルにはまず含まれていません。

投稿2016/10/18 12:52

ippei

総合スコア91

質問の背景は何でしょうか？
EOFは、ファイルの終わりと言うことで、読むべきデータがもう無いと言うことです。つまりデータはありません。
C等では、EOFをプログラム上でデータで扱いたいというニーズのために、「ファイル中に絶対に存在しない値」として、-1を使っています。
他の言語ではまた別の手段でEOFを判断します。

#追記
歴史的なCP/M等の0001 1010 = 0x1A = SUB(substitute)については、ikedasさんの書かれている通りで、EOFというわけでは無いです。ファイルサイズがちょうど128の整数倍のファイルだと0x1Aは付きませんので、「0x1Aが出てくるまで読む」というプログラムはバグと言うことです。

Unix/LinuxのCtrl-D = 0000 0100 = EOT(End of Transmission)は、EOTの名前の通り、直ちにデータを送ります。行頭でCtrl-Dを打つと、readシステムコールが戻り値0つまり「長さゼロのデータが読めた」と返ります。これはディスクファイルがEOFに達したときと同じ戻り値ですが、Unix/Linuxの場合は端末もファイルの一種なので、readが戻り値0の場合はEOFと見なすようコーディングします。getchar関数などはシステムコールに一皮かぶせてあるので、下請けのreadが0を返したら-1を返すようになっています。
つまりシステムコールレベルでは、「readの戻り値が0」というのがEOFです。

投稿2016/10/18 12:50

編集2016/10/18 13:26

otn

総合スコア86295

ikedas

2016/10/18 14:43

補足すると、MS-DOSやその後継のWindowsでは、fopen(3)のモードにテキストモード ("t") とバイナリモード ("b") の区別があって、前者のモードで開いたファイルハンドルでは、EOF (コード0x1A) を読み取った場合と実際にファイル終端に達した場合のいずれでも入力終了とみなすことがあります。

hoge_yama

2016/10/19 11:01

ご回答ありがとうございました。質問の背景としては、ある送られてくるファイルにEOFをつけますという約束ごとがなされており、EOFとは明示的に付加できて、識別できるものかどうかが気になって質問させていただくに至りました。 `EOF`はファイルにそれを表す具体的なバイトではなく、ファイルの終端を抽象化したプログラム上の概念(?)だと理解させていただきました。丁寧な具体例ありがとうございました。