November 2019

S M T W T F S
      12
34 5 678 9
10111213141516
17181920212223
24252627282930

Style Credit

Expand Cut Tags

No cut tags
Monday, October 11th, 2004 12:17 pm
"Как указано выше, обнаружив конец файла, функция getc() возвращает константу EOF. Однако это не самый лучший способ распознавания конца файла. Во-первых, операционная система может работать как с текстовыми, так и с бинарными файлами. Если файл открыт для бинарного ввода, из него может быть считано целое число, равное константе EOF. Следовательно, конец файла, распознаваемый функцией getc(), может не совпадать с реальным концом файла."

Я, наверное, чего-то не понимаю. Как можно считать из файла байт со значением EOF?
Про знаковое расширение у signed char я знаю, но если оно срабатывает на байтах, читаемых из файла, то это тяжелая проблема билиотеки, подлежащая срочному лечению.
Так о чём это он?
Monday, October 11th, 2004 02:39 am (UTC)
Там же написано сями по фоновому:

int getc(FILE *stream);

Именно int, а не char!
Соответственно, прочитать байт 0x1A (что было актуально в DOS) можно, но обрабатывать его именно как EOF никто не заставляет - точно так же, как /bin/sh завершает работу не при чтении символа ^D (0x04), а при получении SIGHUP
Monday, October 11th, 2004 03:00 am (UTC)
/bin/sh все-таки заканчивается, когда во входном файле натыкается на конец. При SIGHUP он кончается не всегда, его можно перехватить коммандой trap. Символ 0x04 -- это не EOF. EOF -- это конкретная константа, в большинстве мест -- это -1 (описание в том же stdio.h). (С другой стороны, чуть ли не единственный интерфейс, в котором импользуется константа EOF -- это getc(), а это совсем не единственный способ читать из файлов даже в stdio. Есть еще fread(), fgets(), fscanf().) Опять же, Control-D на терминале считывается как конец файла из-за драйвера терминала, а не из-за какой-то библиотечной функции.

В приведенном отрывке, конечно, написана ерунда. Не знаю уж, кто виноват, автор или переводчик.