问题描述
*注意：我使用的是windows，所以EOF对我来说是ctrl + Z。
*Note: I'm using windows, so EOF is ctrl + Z for me.
有一段时间，我注意到EOF输入看起来不一样在隔离中比当伴随其他输入时。例如， ^ Z （在命令提示符窗口中的EOF命令）和 a ^ Z 在以下代码中：
For a while I've noticed an EOF input seems to behave differently in isolation than it does when accompanied by other input. For example, ^Z (the EOF command for windows in command prompt) and a^Z seem to cause different behavior in the following code:
#include <stdio.h>
#define MAX 1000
int getline(char s[]);
main() {
int line;
char arr[MAX];
while( (line = getline(arr)) != EOF)
printf("%s",arr);
system("Pause");
return 0;
}
int getline(char s[])
{
int c, i = 0;
while ((c = getchar()) != EOF && c != '\n') {
s[i++] = c;
}
if (c == '\n') {
s[i++] = c;
}
else
return EOF;
s[i] = '\0';
return 1;
}
如果输入 ^ Z +在命令提示符下输入，程序可以跳转到 system（Pause）; 然而，如果我输入 abc ^ code> + enter，没有发生任何事情，因为EOF被忽略，并且从未收到'\\\命令。如果，在这一点上，我再次按回车，它显示如下：
'
If I input ^Z + enter in the command prompt, the program predictably jumps to system("Pause"); However, if I input abc^Z + enter, nothing happens, as though EOF was ignored and a '\n' command was never received. If, at this point, I press enter again, it shows the following:
我一直在修改和调试这个代码和它的小变体一个多小时，找到它的任何错误。理论上，如果我输入 abc ^ Z + enter，我期望输入被解释为 abcEOF\\\ ，其将给出：
I've been tinkering with and debugging this code and small variations of it for over an hour now and can't seem to find anything wrong with it. In theory, if I input abc^Z + enter, I expect the input to be interpreted as abcEOF\n, which would give:
s[0] = 'a'
s[1] = 'b'
s[2] = 'c'
i = 3 when loop breaks from c = EOF
if (c == '\n') skipped since c = EOF
leads to else -> return EOF
in main(), line = EOF since that is what the function getline returned
while loop breaks because of above
system("Pause"); follows
我的代码有问题，我可以忽略，或者有EOF的怪癖命令提示我应该注意？我几乎可以肯定这不是混合 ^ Z 与其他值造成意外行为的唯一实例。
Is there something wrong with my code that I'm overlooking or is there some quirk to EOF or command prompt that I should be aware of? I'm almost certain this isn't the only instance where mixing ^Z with other values caused unintended behavior.
推荐答案
不要将作为文件结束字符，实际上是一个
Don't think of as the end-of-file character, there is actually a real character with code point 26 (which is what you'd normally expect to generate).
CTRL-Z 作为您的终端设备的一种方式来表示您的程序的输入流的结束。如果您要读取磁盘的真实文件，并且它包含，它应该继续（虽然在某些实现中可能不是这样，例如，使用模式 r 而不是 rb 打开它。
Instead, think of as a way for your terminal device to indicate the end of the input stream to your program. If you were to read a real file of the disk and it contained , it should keep going (though that may not be the case in certain implementations where you, for example, open it with the mode r instead of rb).
在Windows中，将转换为结束流操作只会发生在它出现在行的开始当您输入 abc 时，不会获取EOF。
In Windows, that translation of to the end-stream operation only happens when it appears at the start of the line which is why you're not getting EOF when you enter abc.
对不是开头的字符位置，将其视为真实的闭合操作。这就是为什么你会得到→字符，这是在代码点26的可打印字符。
When you enter on a character position that isn't the start of the line, it's treated as a real , not a stream-closing operation. That's why you're getting that → character, which is the printable character at code point 26.
这篇关于伴随其他值时的EOF行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！