2016-12-08 29 views
0
$ cd glibc-2.23 
$ grep -ErI --include='*.c' '= *f?put([cs]|char)\>' |wc -l 
1 
$ grep -ErI --include='*.c' '[^= ] *f?put([cs]|char)\>' |wc -l 
1764 

$ man putc 
... 
RETURN VALUE 
    fputc(), putc() and putchar() return the character written 
    as an unsigned char cast to an int or EOF on error. 

Возможно, это «достаточно маловероятно», что, например, в последовательности putchar s один или два не удается незаметно, а успех и предшествующего из них преуспевают?
Или, по крайней мере, из 99,9999% реализаций, они просто не могут иметь «возвращать такие-то» заявления?
Или непрерывная проверка ошибок после каждого байта (в случае putchar, putc, fputc) может вызвать слишком большую деградацию производительности?Никто, никогда не проверяет возвращаемое значение функций putc, fputc, puts, fputs, putchar (и, возможно, printf). Зачем?

+0

Связанный: http://softwareengineering.stackexchange.com/questions/302730/should-one-check-for-every-little-error-in-c – Downvoter

+0

Я бы сказал, что это комбинация: это неприятность, и ошибки крайне маловероятны, и «не проверяйте ошибки, с которыми вы не справитесь». Но я не думаю, что это производительность. Если вы хотите проверить наличие ошибок записи, и у вас есть много индивидуальных вызовов 'putc', достаточно проверить ошибку возврата на некоторые из них, вам не нужно проверять их все. –

+0

Хороший вопрос о C, но я считаю это слишком мнением, основанным на хорошем ответе здесь на Stack-overflow. Неясно, какой другой сайт SE будет хорош. – chux

ответ

1

Игнорирование возвращаемых значений из функций является источником многих трудноиспользуемых ошибок в программном обеспечении. Ваше утверждение о том, что «никто» проверяет возвращаемые значения, неверно. Высоконадежные программные системы проверяют возвращаемые значения.

0

Они часто игнорируются по нескольким причинам. Во-первых, для большинства систем шансы проблемы с ними достаточно удалены, что большинство людей просто не волнует.

Во-вторых, поскольку, если они не сработают, в любом случае вы можете сделать это относительно мало, если ОС переходит в состояние, при котором запись в файл не выполняется, обычные реакции, такие как отображение сообщения пользователю и/или регистрация ошибки может также сбой.

И, наконец, в большинстве случаев вы можете немного упростить проблему: выполните ввод/вывод, а затем выполните только проверку на ошибку, удалось ли выполнить fclose. Если файл попал в состояние сбоя, вы можете ожидать, что fclose потерпит неудачу, поэтому улавливание ошибки раньше (когда вы делали ввод-вывод), как правило, было только оптимизацией - вы можете обнаружить ту же проблему, только проверив fclose, хотя вы можете потратить некоторое время на бесполезные попытки записать файл после того, как сможете обнаружить проблему.

Даже проверка возврата от fclose является довольно необычным, хотя. У вас все еще есть те же проблемы, о которых говорилось выше: если система не справилась с тем, что она терпит неудачу, существует довольно приличная вероятность того, что большинство ваших попыток реагировать на отказ также потерпят неудачу.

Есть еще некоторые случаи, когда это имеет смысл. Например, рассмотрите возможность перемещения файла из одного места в другое (например, через сеть). Вы хотите проверить, что вы успешно написали данные до места назначения, прежде чем удалять исходный файл. В этом случае проверка возврата с fclose - довольно простой способ уменьшить вероятность уничтожения файла пользователя, если попытка копирования не удалась.

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

  • Нет связанных вопросов^_^