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

问题描述

作为一点背景知识，我对 C 编程语言很陌生，因此一直在尝试完成 Kernighan & 第二版中的一些练习.里奇手册.我确实意识到通过更多地使用标准库，我可能可以更简洁地处理某些问题，但我正在努力使我的有用命令与本书尽可能保持同步.

如果有区别，我正在使用 Tiny C 编译器 (TCC) 在 Windows XP 环境中编译我的源代码，并在 XP 控制台 (cmd.exe) 中执行二进制文件.

问题:处理文件尾(EOF)字符.我整理了一个小测试用例来说明这个问题.该程序似乎处理 EOF 字符(部分).我将尝试通过示例输入/输出来演示该问题.

#include int main(){int 字符，计数；字符 = 0;字符 = getchar();for (count = 0; character != EOF; ++count){字符 = getchar();}printf("计数:%d"，计数);返回0；}

示例输入1:abcd^Z[enter](其中^Z/CTRL+Z代表EOF字符，[enter]代表回车键.)

示例输出 1:Count: 4(等待更多输入或在 ^C/^Z[enter] 上正确结束)

示例输入2:abcd^Zefgh

示例输出 2:Count: 4(等待更多输入或在 ^C/^Z[enter] 上正确结束)

正如在两个示例中所指出的，在启动 ^C/^Z[enter] 序列之前，不会输出字符计数.在启动之前，程序会等待(实际上是处理)更多的输入.但是，如示例 2 中所述，当程序遇到初始 ^Z 时，它会停止处理该行输入，等待更多输入或在启动 ^C/^Z[enter] 序列时返回正确的计数.

我不明白为什么程序只部分处理了 EOF 字符.在我看来，如果它截断了示例 2 的结尾，它也应该完全脱离循环.任何想法为什么在识别 EOF 字符时程序不会立即打印当前计数并退出?

解决方案

这个答案是 unix-ish，但我认为 Windows 上正在发生类似的现象.EOF 的底层形式是零长度的read.在交互式输入设备(终端)上，有一种特殊的机制可以在输入流中包含 EOF，但是如果已经有要读取的输入，它将与该输入一起使用(导致非零长度的 read)，因此从未被应用程序注意到.只有当 EOF 发生时没有预先缓冲的输入才能被应用程序注意到并采取行动.

如果您可以访问 Linux(或其他 *nix)系统，请编写一个类似的测试程序并在 strace 下运行它.观察发生的底层 read 调用，这种不直观行为的原因是有道理的.

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.

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).

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;
}

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

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

Sample input 2: abcd^Zefgh

Sample output 2: Count: 4 (waits for more input or ends properly on ^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.

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?

解决方案

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.

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屋！