Насколько сильно может произойти сбой?

Question

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

Полагаю, это будет зависеть от объема программы? Я имею в виду, если ошибка в программе, которая имела дело с вашим поклонником, скопировала счастливые лица в какое-то важное место в памяти ...?

Мой вопрос: сколько существует мифов в мире зрелищных аварий C? Могу ли я получить конкретные примеры опасных вещей, которых следует избегать?

г.

Answer 1

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

Однако, на самом деле это то же самое со многими другими языками (например, в языке C следует указывать нулевой указатель, в Java использовать ссылку на объект, установленную в значение null, оба приведут к краху вашего процесса).

Итак, я считаю, что с защищенной памятью C не может нанести больше вреда, чем любой другой язык (если ваш процесс не является частью ОС;))

Answer 2

В дни DOS я фактически переписал информацию о биосах. Пришлось получить технику, чтобы это исправить. Мой первый домашний компьютер - 286. Не загружается через день или два.

Answer 3

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

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

Answer 4

Был компьютер Commodore PET 4032 (он же «Fat 40»), на котором действительно можно было постоянно выгорать видеочип, если вы указали неправильное значение в неправильной части памяти. Вы можете себе представить, что если бы на этой машине был компилятор C, дикий указатель мог бы нанести непоправимый физический ущерб компьютеру.

Answer 5

Авария не самая страшная вещь, которая может случиться.

Я читал о старой программе сжатия файлов Unix (вы знаете, как Zip), которая не проверяла возвращаемое значение из fclose. Да, fclose может вернуть ошибку. Вывод в файл обычно буферизуется, поэтому, даже если вызов fwrite или putc кажется работающим и возвращает OK, данные все еще могут находиться в буфере, ожидая записи. Когда вызывается fclose, все неписанные данные сбрасываются, и это может привести к сбою, так как (например) диск может быть заполнен. А поскольку программа сжатия обычно запускалась только , поскольку диск был почти заполнен, это происходило довольно часто. Таким образом, программа молча усекла новый сжатый файл, оригинальный несжатый файл был удален, и в следующем году или около того, когда кто-то пытался распаковать файл, конец отсутствовал!

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

Answer 6

Если рассматриваемое программное обеспечение работает на ПК, оно может «просто» отключить ваш компьютер.

Если, однако, он управляет работой двигателя в вашем автомобиле - или, что еще хуже, ABS - это не просто программное обеспечение, которое дает сбой ...

Answer 7

Вернувшись в колледж, мне было поручено создать многопоточный прокси.

Время от времени прокси не отвечал ни на один из ресурсов, которые перетащила страница. Код, вызывающий проблему:

Некоторый код с проблемами переполнения, который использовал переменные рядом с обработчиком файла. Прежде чем узнать, что происходит, я обнаружил, что действительно странно, что перемещение объявления обработчика файлов «решило» проблему, смеется.

Ps. отметьте это (не в c, но хорошая история :)): http://trixter.wordpress.com/2006/02/02/computing-myth-1-software-cannot-damage-hardware/

Answer 8

Когда я писал драйверы для Win98, BSOD преследовал всех. Я помню следующую ошибку, которую я сделал

typedef struct _SOME_TAG_ {

    int nSomeVar;
    int nSomeMore;
    ...

} MYSTRUCT, * PMYSTRUCT;

.... PMYSTRUCT pMyStruct;

// И я использую эту структуру без выделения памяти ;-) pMyStruct-> nSomeVar = 0;

И сбои в работе водителя были настолько ужасными, но у нас был SoftICE от Numega, хотя это всего лишь 10 лет назад .. Я чувствую, что это было в возрасте

Answer 9

C позволяет вам иметь дело с машиной довольно близко к прямой. Насколько впечатляюще он может разбиться, зависит от того, что может делать машина.

Итак: процесс в пользовательском режиме без особых привилегий в хорошей современной операционной системе на самом деле не так уж много делает. Но у вас есть программное обеспечение повсюду. Подумайте о программном обеспечении, управляющем тормозными системами в поезде. Подумайте о программном обеспечении для экстренной внутренней связи, когда кому-то действительно нужна помощь. Подумайте о программном обеспечении, управляющем указателями на оживленной трассе. Подумайте о программном обеспечении под управлением управляемой ракетной системы.

В наши дни программное обеспечение повсюду. Многое написано на C.

Answer 10

Ну, еще во времена DOS мне удалось перезаписать часть загрузочного сектора - ничего подобного перезагрузке, чтобы найти «OS Not Found» или что-то подобное.

Вы учитесь трудному способу очень, очень осторожной записи на диск после этого ...