1

在 C99 的第 7.19.7.1 节中，我们有：

如果未设置 stream 指向的输入流的文件结束指示符并且存在下一个字符，则 fgetc 函数将该字符作为转换为 int 的无符号字符获取，并推进流的关联文件位置指示符（如果定义）。

据我了解，inttype 可以与 a 具有相同的宽度unsigned char。int在这种情况下，我们是否可以得出结论，只有当width > CHAR_BIT时 fgetc 才能正常工作。

（参考 blagovest 的评论），C99 是否指定何时需要标准库，或者是否符合标准的实现可以实现标准库的一部分而不是全部？

4

2 回答 2

2

fgetc返回EOF文件结束或错误条件。

否则，它会将读取的字符返回为unsigned char，转换为int。

假设CHAR_BIT == 16和sizeof (int) == 1，并假设读取的下一个字符的值为 0xFFFF。然后fgetc()将返回 0xFFFF 转换为int.

这里有点棘手。由于 0xFFFF 不能用 type 表示int，因此转换的结果是实现定义的。但通常，结果将是 -1，这是EOF.

所以在这样的系统上，即使它成功读取了一个字符fgetc()也可以返回。EOF

这里没有矛盾。在文件结尾或错误时fgetc()返回的标准保持不变。EOF它并没有反过来说。返回EOF并不一定意味着存在错误或文件结束条件。

您仍然可以通过调用and来确定是否fgetc()读取实际字符。feof()ferror()

所以这样的系统会破坏典型的输入循环：

while ((c = fgetc()) != EOF) {
    ...
}

但它不会（必然）不符合标准。

（参考 blagovest 的评论），C99 是否指定何时需要标准库，或者是否符合标准的实现可以实现标准库的一部分而不是全部？

“托管实现”必须支持整个标准库，包括<stdio.h>.

“独立实施”不需要支持<stdio.h>；只有不声明任何函数的标准头文件（<limits.h>,<stddef.h>等）。<stdio.h>但是如果它选择，一个独立的实现可以提供。

通常独立的实现是针对嵌入式系统的，通常没有操作系统。

实际上，我知道的每个当前托管实现都有CHAR_BIT==8. 这意味着在实践中，您可能可以依靠实际指示文件结束或错误的EOF结果——但标准并不能保证这一点。fgetc()

于 2011-11-15T11:01:32.523 回答
0

是的，在这样一个平台上，会有一个unsigned char值与EOF.

unsigned char不允许有填充字节，因此 的值unsigned char集将是 的可能值的超集int。

在这样一个平台上，唯一的希望是至少char会被签名，这样EOF就不会与积极的char价值观发生冲突。

这可能不是这样一个平台会遇到的唯一问题。

于 2011-11-15T09:36:42.533 回答