Блог

В качестве небольшой справки скажу, что я довольно новичок в языке программирования C и поэтому пытался выполнить некоторые упражнения из второго издания руководства Кернигана и Ричи. Я понимаю, что, вероятно, мог бы более лаконично решать некоторые проблемы, чаще используя стандартную библиотеку, но я пытаюсь максимально синхронизировать свой набор полезных команд с книгой.

Если это имеет значение, я компилирую свой исходный код в среде Windows XP с использованием компилятора Tiny C (TCC) и выполняю двоичные файлы в консоли XP (cmd.exe).

Проблема: обработка End-of-File (EOF) characters . Я собрал небольшой тестовый пример, чтобы проиллюстрировать проблему. Похоже, что программа обрабатывает символ EOF (частично). Я попытаюсь продемонстрировать проблему с примерами ввода / вывода.

 #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[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, но я думаю, что аналогичный phenonemon происходит в Windows. Базовая форма EOF — нулевой длины read . На интерактивных устройствах ввода (терминалах) существует специальный механизм для наличия EOF во входном потоке, но если уже есть входные данные для чтения, они будут использованы вместе с этим вводом (в результате чего получится ненулевая длина read ) и, таким образом, никогда не будут замечены приложением. Только когда EOF происходит без предварительного буферизации входных данных, приложение может это заметить и отреагировать на него.

Если у вас есть доступ к Linux (или другой * nix) системе, напишите аналогичную тестовую программу и запустите ее под strace . Посмотрите на основные read вызовы, которые происходят, и причина этого, в противном случае неинтуитивного поведения, будет иметь смысл.

Это восходит к каменному веку вычислительной техники. По крайней мере, CP / M, возможно, дольше, чем в операционных системах раннего декабря. CP / M не сохранял размер файла, он только отслеживал количество секторов диска, по 128 байт в каждом. Это не проблема для двоичных файлов, программа просто прекращает чтение, когда у нее достаточно. Но, безусловно, проблема для текстовых файлов.

Итак, по соглашению, конец текстового файла был отмечен кодом 0x1a, Control Z. Из-за устаревших текстовых файлов, размер которых превышал объем текста в них, это приходилось переносить в каждом последующем поколении реализаций CRT. Windows на это наплевать, это чисто деталь реализации CRT. Вот почему ввод Ctrl Z на консоли не приводит к чему-то особенному. Как только вы нажмете Enter, ЭЛТ в cmd.exe снова вызывает устаревшее поведение и объявляет EOF.

Я не знаю наверняка с TCC, но в довольно многих (большинстве?) случаев вам нужно ввести ^ Z более или менее отдельно, чтобы он был распознан как EOF (т. Е. вам нужна последовательность [enter] ^ z [enter]).

EOF не генерируется Windows автоматически при вводе ^ Z; это просто соглашение, перенесенное из DOS. Среда выполнения вашего компилятора C должна распознать это и установить флаг EOF, и я предполагаю, что Tiny C этого не делает.

^ C, с другой стороны, распознается командной средой Windows. Это не обязательно означает EOF, я думаю, это скорее сигнал прерывания.

Я бы предположил, что стандартный ввод выполняется с буферизацией строк (это в Unix). В DOS были некоторые getch() и getche() функции более низкого уровня, чем stdio, поэтому они обходят буферизацию stdio. Я не знаю, как отключить буферизацию ввода в Windows, в Unix это делается путем установки терминала в неканонический режим.