fgetc，检查EOF

在Linux系统编程一书中我读过这样的文章：

fgetc将读取的字符作为unsigned char强制转换为文件末尾或错误的int或EOF 。 使用fgetc的常见错误是： 

 char c; if ((c = fgetc()) != EOF) {...}

这段代码的正确版本是： 

 int c; if ((c = fgetc()) != EOF) { printf("%c", (char)c); ... }

那么，为什么我不能在与EOF比较之前将返回值转换为char ？ 为什么我必须将EOF与int进行精确比较？ 当EOF定义为-1 ，它是否通常被转换为char ？
是否有平台/编译器不适用？

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

通常它是-1但你不应该假设。

从c-faq网站上查看这个很棒的答案：

如果在上面的片段中，getchar的返回值被赋值给char，则可能出现两种失败模式。

  1. 如果char类型被签名，并且如果EOF被定义为（通常）为-1，则小数值为255的字符（’\ 377’或C中的’\ xff’）将被符号扩展并将等于EOF，过早地终止输入。 （假设8位字符）。

  2. 如果char类型是无符号的，则实际的EOF值将被截断（通过丢弃其高阶位，可能导致255或0xff）并且不会被识别为EOF，从而导致无限输入。

希望能帮助到你！

编辑:(在这个答案上添加@FatalError评论，这在c-faq网站上有解释，但这对我来说更清楚）

“如果你将它转换为char，那么EOF与某个有效字符的值相同，因此与该字符无法区分。仅此一点就足以certificate不能使结果成为字符”@FatalError注释。

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

  • char是签名值。 在这种情况下，有一个合法的角色（通​​常是ÿ，带有DIAERESIS的小拉丁文字母，U + 00FF）会被误解为EOF。
  • char是无符号值。 在这种情况下，EOF将被转换为0xFF，然后作为正值提升为int ，它将永远不会等于EOF，这是一个负值。

无论哪种方式，该计划将在某些时候行为不端。

（或者，更确切地说，曾经是）编译器错误的可能性，使得分配正确发生但分配的值不用于比较。 这将导致代码看起来工作正常，即使它不是。 幸运的是，这不太可能是现代编译器中的问题。

Interesting Posts