*可能*未签名的字符等于EOF吗? [英] *Might* an unsigned char be equal to EOF?

问题描述

在使用 fgetc 读取流的下一个字符时，通常会检查文件末尾不是通过

When using fgetc to read the next character of a stream, you usually check that the end-of-file was not attained by

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

其中 c 是 int 类型.然后，要么达到文件末尾并且条件将失败，要么 c 是将 unsigned char转换为 int 的char，预期与 EOF 不同-对于 EOF ，确保为负数.很好...显然.

where c is of int type. Then, either the end-of-file has been attained and the condition will fail, or c shall be an unsigned char converted to int, which is expected to be different from EOF —for EOF is ensured to be negative. Fine... apparently.

但是有一个小问题...通常 char 类型的位数不超过8位，而 int 的位数至少必须为16位，因此每个 unsigned char 将表示为 int .但是，在 char 将具有16或32位的情况下(我知道，实际上从来没有这种情况……)，没有理由为什么没有 sizeof(int)== 1 ，因此(从理论上讲！) fgetc(流)返回 EOF (或另一个负值)是可能的，但最终-尚未达到文件...

But there is a small problem... Usually the char type has no more than 8 bits, while int must have at least 16 bits, so every unsigned char will be representable as an int. Nevertheless, in the case char would have 16 or 32 bits (I know, this is never the case in practice...), there is no reason why one could not have sizeof(int) == 1, so that it would be (theoretically!) possible that fgetc (stream) returns EOF (or another negative value) but that end-of-file has not been attained...

我误会了吗?如果尚未达到文件末尾，C标准中是否有某些东西阻止 fgetc 返回 EOF ?(如果是，我找不到它！).还是 if((c = fgetc(stream))！= EOF)语法不完全可移植?...

Am I mistaken? Is it something in the C standard that prevents fgetc to return EOF if end-of-file has not been attained? (If yes, I could not find it!). Or is the if ((c = fgetc (stream)) != EOF) syntax not fully portable?...

的确，这是问题#3860943的重复.我在第一次搜索时没有发现这个问题.谢谢您帮忙！:-)

Indeed, this was a duplicate of Question #3860943. I did not find that question at first search. Thank for your help! :-)

推荐答案

如果您正在读取的是仅标准ASCII的流，则没有风险在实际文件结尾之前接收与EOF等效的char.ASCII字符码最多只能为127.但是在读取二进制文件时可能会发生.该字节必须为255(无符号)才能与-1有符号的char相对应，并且没有阻止它出现在二进制文件中的情况.

If you are reading a stream that is standard ASCII only, there's no risk of receiving the char equivalent to EOF before the real end-of-file, because valid ASCII char codes go up to 127 only. But it could happen when reading a binary file. The byte would need to be 255(unsigned) to correspond to a -1 signed char, and nothing prevents it from appearing in a binary file.

但是关于您的特定问题(如果标准中有某些内容)，不完全是...但是请注意，fgetc将字符提升为未签名的字符，因此在这种情况下，它永远不会是负数.唯一的风险是您是否已将返回值显式或隐式地转换为带符号的char(例如，如果您的c变量为带符号的char).

But about your specific question (if there's something in the standard), not exactly... but notice that fgetc promotes the character as an unsigned char, so it won't ever be negative in this case anyway. The only risk would be if you had explicitly or implicitly cast down the return value to signed char (for instance, if your c variable were signed char).

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

NOTE: as @Ulfalizer mentioned in the comments, there's one rare case in which you may need to worry: if sizeof(int)==1, and you're reading a file that contains non-ascii characters, then you may get a -1 return value that is not the real EOF. Notice that environments in which this happens are quite rare (to my knowledge, compilers for low-end 8-bit microcontrollers, like the 8051). In such a case, the safe option would be to test feof() as @pmg suggested.

这篇关于*可能*未签名的字符等于EOF吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！