私はC11標準のセクション7.21を読みました<stdio.h>。この規格では、最初にストリームを次のように説明しています。
7.21.2.2:
テキストストリームは、文字の順序付けられたシーケンスです...
7.21.2.3:
バイナリストリームは、文字の順序付けられたシーケンスです...
これはストリーム文字のタイプを指定しません(これは方向に依存するため)。それは後で言います:
7.21.3.12:
...バイト出力関数は、fputc関数を連続して呼び出すかのように、文字をストリームに書き込みます。
fputc(7.21.7.3.2)から:
この関数は、で指定された(に変換された)文字を、 ..で示される出力ストリームに
fputc書き込みます。cunsigned charstream
これは、のint c引数がストリームに書き込まれる前にfputc変換されることを示します。unsigned char同様の注意が:に与えられfgetcます
7.21.7.1.2:
関数は、その文字をに変換された
fgetcものとして取得しますunsigned charint
およびungetc、freadおよびfwrite。
これはすべて、内部的にはバイト指向のストリームがsで表されることを示唆していますunsigned char。
ただし、Linuxカーネルの内部を見ると、ファイルはのストリームと見なされているようですchar。私がこれを言っている理由の1つは、file_operations readとwritecallbacksがそれぞれchar __user *とを取得することconst char __user *です。
の実装では、glibcはで定義されています。これでも、すべての読み取りおよび書き込みポインターはです。FILEtypedefstruct _IO_FILElibio/libio.hstructchar *
C ++では、basic_ostream::write関数はconst char *入力と同様に受け取りますbasic_istream::read(ただし、この質問ではC ++には興味がありません)。
私の質問は、上記の引用は、FILEストリームがのストリームとして脅威にさらされるべきであることを意味しますunsigned charか?もしそうなら、なぜglibcとLinuxカーネルはそれらを実装するのchar *ですか?そうでない場合、なぜ標準は文字をに変換することを主張するのunsigned charですか?