2013-09-28 3 views
0
char ch; 
while((ch = getchar()) != EOF){ 
    putchar(ch); 
} 

Приведенный выше код, очевидно, должен скопировать мой ввод. И он работает, для основных текстовых файлов ASCII.getchar() неожиданное поведение

Однако, если я отправлю его gif, в частности, этот, но применим к большинству (http://www.cs.utexas.edu/~peterson/prog2/smile.gif), тогда, когда я перенаправляю stdin для gif и stdout на любой тип файла, а также выполняю diff на оригинале и новый, ошибки в изобилии. В этом случае более половины файла даже не обрабатывается, оно просто завершается. Любые подсказки? Я бы хотел переключиться на другие функции ввода/вывода, если я могу вводить байты за раз.

+1

'getchar' читает стандартный ввод как текст, а не обычный двоичный код. 'gif' - это двоичный файл. – lurker

+0

Да, открытые двоичные файлы в виде двоичных файлов. –

+3

getchar возвращает int, а не символ. – rici

ответ

3

getchar возвращает int, а не char. Различие важно, потому что оно может вернуть EOF, что является значением, которое не может быть символом.

Вы не можете надежно проверить EOF, если вы конвертируете возвращаемое значение getchar в char. Цикл прекратится, когда вы нажмете символ, значение которого равно (char)EOF.

Исправить, объявив ch как int.

+0

Значение, возвращаемое getchar(), исключая EOF, все еще находится в пределах нормального символа?, Поэтому нет 2^30 ...? – pbae

+0

Не могли бы вы подробнее рассказать о том, что вы подразумеваете под его ненадежностью? – pbae

+1

На самом деле, я просто посмотрел. Это поведение определяется стандартом, поэтому getchar() всегда возвращает либо EOF, либо целое число в диапазоне, представляемом как * unsigned * char, независимо от того, подписан ли символ char или unsigned. Вы не можете считать EOF равным -1; просто, что он не находится в диапазоне unsigned char. – rici

Смежные вопросы