检查EOF

Question

在Linux系统编程一书中，我读过这样的一些内容：

fgetc在文件或错误结束时将读取为unsigned char的字符返回给int或EOF。使用fgetc的一个常见错误是： (c=fgetc() != EOF) {.} 此代码的正确版本是： (c= fgetc()) != EOF) { printf("%c"，(char)c)；.}

那么，为什么在与char比较之前，我不能将返回值转换为EOF呢？为什么我必须准确地比较EOF和int呢？正如EOF定义为-1，它不是通常被抛给char吗？

是否存在不正确的平台/编译器？

Answer 1

您不能将返回值转换为char，因为返回值可能是EOF，而且EOF值与系统相关，并且不等于任何有效的字符代码。链接

通常是-1，但您不应该假设这一点。

检查现场的这个很好的答案

如果像上面的片段一样，将getchar的返回值分配给char，则有可能出现两种失败模式。

1. 如果char类型被签名，如果EOF被定义为-1，则小数值255的字符(C中的‘\377’或'\xff‘)将进行符号扩展，并与EOF相比较，过早终止输入。(假设8位字符)。
2. 如果char类型是无符号的，那么实际的EOF值将被截断(通过丢弃其高阶位，可能导致255或0 0xff)，并且不会被识别为EOF，从而导致有效的无限输入。

希望能帮上忙！

编辑：(添加了@FatalError对这个答案的评论，这是在clear网站上解释的，但在我看来这一点更清楚)

@FatalError评论@FatalError评论：“如果你把它转换成字符，那么EOF就会得到与某个有效字符相同的值，因此就无法与该字符区分开来。仅凭这一点就足以证明结果不是一个字符。”

Answer 2

在与EOF比较之前将值赋值给char时，有两种可能性：

• char是一个有符号的值。在这种情况下，有一个合法的字符(通常是小写拉丁语字母Y，带U+00FF)会被误解为EOF。
• char是一个无符号值。在这种情况下，EOF将被转换为0xFF，然后作为一个正值提升到int，这个值永远不会与一个负值EOF相比较。

不管是哪种方式，这个程序在某些时候都会表现不正常。

有一个编译器错误的机会(或者更准确地说，过去是这样)，这样赋值就会正确地发生，但是指定的值不会用于比较。这将导致代码看起来正常工作，即使它不是。幸运的是，这不太可能是在现代编译器中发现的问题。