为什么我需要多个EOF（CTRL + Z）字符？ [英] Why do I require multiple EOF (CTRL+Z) characters?

问题描述

作为一个小的背景下，我很新的C语言程序设计，因此一直在试图通过一些在Kernighan的＆放大器的第二版的练习工作;里奇手册。我也知道我大概可以处理某些问题更简洁地利用标准库的更多，但我想尽可能多的保持我有用的命令的剧目与书同步越好。

As a little background, I am quite new to the C Programming Language and as such have been attempting to work through some of the exercises in the second edition of the Kernighan & Ritchie manual. I do realize that I could probably deal with certain issues more succinctly by utilizing the standard library more, but am trying to keep my repertoire of useful commands in sync with the book as much as possible.

如果它的确与众不同，我编我在使用微小的C编译器（TCC）在Windows XP环境的源和我执行XP控制台（CMD.EXE）中的二进制文件。

If it makes a difference, I am compiling my source in a Windows XP environment using the Tiny C Compiler (TCC) and am executing the binaries within the XP Console (cmd.exe).

问题：处理档案结尾（EOF）字符。我已经把一个小的测试案例来说明这个问题。该方案似乎处理EOF字符（部分）。我会尝试与样品输入/输出来证明这个问题。

Problem: handling of End-of-File (EOF) characters. I've put together a small test case to illustrate the issue. The program seems to handle the EOF character (partially). I will try to demonstrate the issue with sample inputs/outputs.

#include <stdio.h>

int main() 
{
    int character, count;

    character = 0;
    character = getchar();

    for (count = 0; character != EOF; ++count) 
    {
        character = getchar();
    }

    printf("Count: %d", count);
    return 0;
}

样品输入1： ABCD ^ Z [进入] （其中^ Z / Ctrl + Z重新presents EOF字符和[进入]再presents回车键）。

Sample input 1: abcd^Z[enter] (where ^Z/CTRL+Z represents the EOF character and [enter] represents the Enter key.)

样输出1：计数：4 （输入更多等待或结束上正确^ C / ^ Z [进入]）

Sample output 1: Count: 4 (waits for more input or ends properly on ^C/^Z[enter])

输入示例2： ABCD ^ Zefgh

示例输出2：计数：4 （输入更多等待或结束上正确^ C / ^ Z [进入]）

Sample output 2: Count: 4 (waits for more input or ends properly on ^C/^Z[enter])

如在这两个例子中所指出的，直到一个^ C / ^ Z [输入]序列被启动的字符计数不输出。直到开始，程序等待（实际上处理）更多的输入。然而，如上所述例如2，当程序遇到的初始^ Z，它会停止处理该行输入，等待更多的输入，或者如果^ C / ^ Z [Enter]键序列开始返回正确的计数

As noted in both examples, the character count is not output until a ^C/^Z[enter] sequence is initiated. Until initiated, the program waits (and indeed processes) more input. However, as noted in example 2, when the program encounters the initial ^Z, it stops processing that line of input, waiting for more input or returning the correct count if a ^C/^Z[enter] sequence is initiated.

我想不通为什么程序仅部分处理EOF字符。在我看来，如果它被截去样品2月底，这也应该是突破了完全的循环。任何想法，为什么在承认了一个EOF字符的计划不会立即打印当前计数并退出？

I can't figure out why the program is only partially handling the EOF character. Seems to me that if it is truncating the end of sample 2 that it should also be breaking out of the loop entirely. Any ideas why upon recognition of an EOF character the program doesn't immediately print the current count and exit?

推荐答案

这答案是UNIX十岁上下，但我认为类似的phenonemon在Windows上发生的事情。一个EOF的基本形式是零长度读。交互式输入设备（终端），对于具有在输入流中一个EOF一种特殊的机制，但是，如果已经有输入要读取，将与该输入一起被消耗（产生一个非零长度读），因此不会被应用注意。只有当EOF用缓冲之前没有输入时可以将它被注意到，并且由应用采取行动。

This answer is unix-ish, but I think a similar phenonemon is happening on Windows. The underlying form of an EOF is a zero-length read. On interactive input devices (terminals), there is a special mechanism for having an EOF in the input stream, but if there's already input to be read, it will be consumed along with that input (resulting a non-zero length read) and thus never noticed by the application. Only when the EOF occurs with no prior input buffered can it be noticed and acted upon by the application.

如果你有机会到Linux（或其他* nix中）系统，写一个类似的测试程序，并在 strace的运行。手表发生的根本读电话，并为此否则，非直观的行为之所以会是有意义的。

If you have access to a Linux (or other *nix) system, write a similar test program and run it under strace. Watch the underlying read calls that happen, and the reason for this otherwise-unintuitive behavior will make sense.

这篇关于为什么我需要多个EOF（CTRL + Z）字符？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！