Question

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

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

据我了解，int类型可以与unsigned char具有相同的宽度。在这种情况下，我们可以得出结论，只有int宽度＆gt; fgetc才能正常运行。 CHAR_BIT。

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

Answer 1

fgetc会在文件结束或错误情况下返回EOF。

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

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

这里有点棘手。由于0xFFFF无法在类型int中表示，因此转换的结果是实现定义的。但通常情况下，结果将为-1，这是EOF的典型值（实际上是我听过的唯一值）。

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

这里没有矛盾。标准保留fgetc()在文件结尾或错误时返回EOF。它并没有反过来说;返回EOF并非必然暗示存在错误或文件结束条件。

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

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

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

但它（不一定）不符合标准。

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

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

“独立实施”不需要支持<stdio.h>;只有不声明任何函数的标准标题（<limits.h>，<stddef.h>等）。但是，如果选择的话，独立实施可能会提供<stdio.h>。

通常，独立式实施适用于嵌入式系统，通常没有操作系统。

实际上，我所知道的每个当前托管实现都有CHAR_BIT==8。这意味着在实践中你可以可能指望来自EOF的{{1}}结果实际指示文件结束或错误 - 但标准不是保证它。

Answer 2

是的，在这样的平台上，有一个unsigned char值与EOF无法区分。

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

在这样一个平台上唯一的希望就是至少char会被签名，因此EOF不会与正char值冲突。

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