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

Question

我已经通读了 C11 标准的第 7.21 节，其中 <stdio.h>被描述。该标准首先将流描述为:

7.21.2.2:

A text stream is an ordered sequence of characters ...

7.21.2.3:

A binary stream is an ordered sequence of characters ...

它没有指定流字符的类型(因为这取决于方向)。它后来说:

7.21.3.12:

... The byte output functions write characters to the stream as if by successive calls to the fputc function.

来自 fputc (7.21.7.3.2):

The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream ...

表示int c fputc 的参数转换为 unsigned char在写入流之前。 fgetc 给出了类似的注释:

7.21.7.1.2:

the fgetc function obtains that character as an unsigned char converted to an int

和ungetc , fread和 fwrite .

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

但是，查看 Linux 内核的内部结构，文件似乎被认为是 char 的流。 .我这么说的原因之一是 file_operations read和 write回调得到 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 ?

Answer 1

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

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

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

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

负字符有符号字符。