*可能*未签名的字符等于EOF？

Question

当fgetc用于读取流的下一个字符时,通常会检查是否未达到文件结尾

if ((c = fgetc (stream)) != EOF)

哪里c是int类型.然后,文件结束已经达到并且条件将失败,或者c应该是unsigned转换为的char int,预期与EOF-c 不同,因为EOF确保为负.很好......显然.

但是有一个小问题......通常char类型不超过8位,而且int必须至少有16位,所以每个unsigned char都可以表示为int.然而,在这种情况下char会有16或32位(我知道,在实践中情况从来都不是这样......),没有理由为什么人们不能拥有sizeof(int) == 1,所以它(理论上!)可能fgetc (stream)返回EOF(或另一个负值)但文件结尾尚未达到......

我错了吗？如果没有达到文件结尾,C标准中是否会阻止fgetc返回EOF？(如果是的话,我找不到它!).或者if ((c = fgetc (stream)) != EOF)语法不完全可移植？...

编辑:的确,这是问题#3860943的重复.我在第一次搜索时没有找到这个问题.谢谢您帮忙!:-)

Answer 1

如果您正在读取仅标准 ASCII 的流，则不会有在真正的文件结束之前接收到相当于 EOF 的字符的风险，因为有效的 ASCII 字符代码最多可达 127。但在读取二进制文件时可能会发生这种情况。该字节需要为 255（无符号）才能对应于 -1 有符号字符，并且没有什么可以阻止它出现在二进制文件中。

但是关于您的具体问题（如果标准中有某些内容），不完全是...但请注意 fgetc 将字符提升为无符号字符，因此在这种情况下无论如何它都不会为负数。唯一的风险是，如果您显式或隐式地将返回值强制转换为有符号字符（例如，如果您的 c 变量是有符号字符）。

注意：正如 @Ulfalizer 在评论中提到的，有一种罕见的情况你可能需要担心：如果 sizeof(int)==1，并且你正在读取一个包含非 ASCII 字符的文件，那么你可能会得到一个-1 返回值不是真正的 EOF。请注意，发生这种情况的环境非常罕见（据我所知，低端 8 位微控制器的编译器，如 8051）。在这种情况下，安全的选择是按照 @pmg 的建议测试 feof() 。