私は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
書き込みます。c
unsigned char
stream
これは、のint c
引数がストリームに書き込まれる前にfputc
変換されることを示します。unsigned char
同様の注意が:に与えられfgetc
ます
7.21.7.1.2:
関数は、その文字をに変換された
fgetc
ものとして取得しますunsigned char
int
およびungetc
、fread
およびfwrite
。
これはすべて、内部的にはバイト指向のストリームがsで表されることを示唆していますunsigned char
。
ただし、Linuxカーネルの内部を見ると、ファイルはのストリームと見なされているようですchar
。私がこれを言っている理由の1つは、file_operations read
とwrite
callbacksがそれぞれchar __user *
とを取得することconst char __user *
です。
の実装では、glibc
はで定義されています。これでも、すべての読み取りおよび書き込みポインターはです。FILE
typedef
struct _IO_FILE
libio/libio.h
struct
char *
C ++では、basic_ostream::write
関数はconst char *
入力と同様に受け取りますbasic_istream::read
(ただし、この質問ではC ++には興味がありません)。
私の質問は、上記の引用は、FILEストリームがのストリームとして脅威にさらされるべきであることを意味しますunsigned char
か?もしそうなら、なぜglibc
とLinuxカーネルはそれらを実装するのchar *
ですか?そうでない場合、なぜ標準は文字をに変換することを主張するのunsigned char
ですか?