面向字节的 FILE 流是否包含 `char` 或 `unsigned char`？

Question

我已通读 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指向的输出流...

这表示fputc 的int c 参数在写入流之前转换为unsigned char。 fgetc 也有类似的注释：

7.21.7.1.2：

fgetc 函数将该字符作为unsigned char 转换为int

和ungetc、fread 和fwrite。

现在这一切都暗示在内部，面向字节的流由unsigned chars 表示。

但是，查看 Linux 内核的内部结构，文件似乎被视为char 的流。我这么说的一个原因是 file_operations read 和 write 回调分别得到 char __user * 和 const char __user *。

在glibc的实现中，FILE是struct _IO_FILE的typedef，在libio/libio.h中定义。同样在这个struct中，所有的读写指针都是char *。

在 C++ 中，basic_ostream::write 函数以 const char * 作为输入，同样以 basic_istream::read 为输入（但我对这个问题中的 C++ 不感兴趣）。

我的问题是，上面的引用是否暗示 FILE 流应该作为unsigned char 的流受到威胁？如果是这样，为什么glibc 和Linux 内核用char * 来实现它们？如果不是，为什么标准坚持将字符转换为unsigned char？

Answer 1

这并不重要。标准在某些选定的地方使用 unsigned char，因为它允许在这些地方进行精确的表述：

• fgetc 指定返回转换为 int 的无符号字符，以便知道结果是正数或空值，但 EOF 除外（因此 EOF 和有效字符之间不会混淆，当一个人直接将 fgetc 的结果存储在一个字符中而不事先检查 EOF 时，混淆是导致错误的原因）。

• fputc 被指定为采用 int 并将其转换为 unsigned char，因为此转换已明确指定。如果你不小心，不使用 unsigned char 的公式可能会使 UB 像

  int c = fgetc(stdin);
  if (c != EOF)
      fputc(c, stdout);
  

负字符用有符号字符。

Answer 2

这并不重要。 char 的长度为 CHAR_BIT 位（limits.h - 通常为 8 位），无论是否已签名。

这些函数适用于CHAR_BIT 位块，因此符号在此处对写入或读取过程没有影响。

然后，您可以通过适当地转换结果来使用有符号或无符号字符，具体取决于您的应用程序逻辑。人类表示会有所不同，具体取决于符号，但对于处理器来说，表示不会改变。它仍然是字节。

Answer 3

您唯一可以直接观察（无需检查来源）的是 API 返回的内容。它背后的任何东西都被黑盒抽象所隐藏，不应该是你关心的问题。

关于您问题的另一部分：标准必须注意，有一个转换，因为参数/返回值是int 并且流是字符序列。