The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск ControlFlag 1.0, инструмента для выявления ошибок в коде на языке Си, opennews (ok), 19-Ноя-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


94. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +3 +/
Сообщение от Аноним (31), 20-Ноя-21, 12:25 
> Почему бы алгоритму этот смысл не вычислить?
> Нет, не исключена. В C enum может содержать _любое_ значение.

У вас нет опыта разработки.

Если разработчик может допустить "_любое_" значение в переменных, имеющих конкретный смысл и конкретный спектр принимаемых значений, то он немедленно признаётся профнепригодным и увольняется.

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

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


Если вы считаете, что алгоритмы должны сами "вычислять смысл", то программирование -- это не ваша сфера.

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

99. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +1 +/
Сообщение от Аноньимъ (ok), 20-Ноя-21, 13:20 
>Поэтому любой нормальный программист пишет код так, чтобы при малейшей ошибке, возникающей по вине внутренних переменных, программа упала сразу и со сброшенным на диск дампом.
>Потому что источником неверных и некорректных значений может быть только внешняя среда -- пользователь, некорректные настройки, etc. -- "_любое_" значение может прийти только отсюда. Именно эти значения проверяются и исправляются, когда возможно.
>Если "_любые_" значения появляются в других местах, значит программа генерирует неверные значения и работать корректно не может в принципе.

Так, а как ТАК пишут код чтобы программа СРАЗУ упала при ошибке во внутренних переменных без проверок этих внутренних значений на корректность?

Ответить | Правка | Наверх | Cообщить модератору

120. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  –1 +/
Сообщение от Аноним (31), 20-Ноя-21, 15:05 
Ну, например, если передать NULL в dest в strcpy(), то будет ошибка сегментации и работать ничего не будет.
Если наша программа такова, что dest -- при корректной работе проги -- не может быть нулевым, то некорректную работу мы увидим сразу.

А если strcpy() не упадёт, а каким-то образом скажет "ОШИБКА: у вас в dest передан NULL, копирование невозможно", то возникнет сразу пачка проблем:

1. Программа продолжит работать, хотя часть её -- копирование -- не было выполнено;
   смысла в таком продолжении нет, потому что данные уже некорректны.
   Поэтому программа упадёт где-то в другом месте, и вам придётся основательно шерстить код, чтобы найти первопричину.

   И ещё худший вариант: программа не упадёт, а испортит какие-то данные или недовыполнит какого-то действия, а вы этого не заметите;

2. Если вывод будет проводиться в stderr/stdout, то тоже проблема: многие процессы не имеют потока вывода и никто сообщения не увидит.
   У многих других объём вывода такой, что сообщения никто не заметит.

   Поэтому сценарий будет как в п.1, только уже у клиента в релизной версии (т.е. раз оно уже запускается как демон, то, скорее всего, дебаг с потоками вывода уже успешно завершён).

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

Поэтому программа при _внутренних_ ошибках -- зависящих _только_ (подчёркиваю подчёркиваниями) от устройства программы и ни от чего больше -- должна упасть сразу.
Это сэкономит вам время во время отладки.

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

Ответить | Правка | Наверх | Cообщить модератору

122. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +/
Сообщение от Аноним (31), 20-Ноя-21, 15:08 
Пример с NULL в strcpy(), ессно, слишком толстый.
Но он примерно показывает суть, когда надо падать, а когда -- проверять, корректировать или штатно завершать работу с кодом ошибки.
Ответить | Правка | Наверх | Cообщить модератору

124. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +1 +/
Сообщение от Аноньимъ (ok), 20-Ноя-21, 15:15 
>Поэтому программа при _внутренних_ ошибках -- зависящих _только_ (подчёркиваю подчёркиваниями) от устройства программы и ни от чего больше -- должна упасть сразу.

А она знает что она должна упасть?

Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

100. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +1 +/
Сообщение от Ordu (ok), 20-Ноя-21, 13:42 
> Если разработчик может допустить "_любое_" значение в переменных, имеющих конкретный смысл
> и конкретный спектр принимаемых значений, то он немедленно признаётся профнепригодным
> и увольняется.

Хахахаха. Это ты так троллить пытаешься?

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

107. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +2 +/
Сообщение от _kp (ok), 20-Ноя-21, 14:06 
>> нормальный программист пишет код так, чтобы при малейшей ошибке,
>> возникающей по вине внутренних переменных, программа упала сразу и со сброшенным на диск дампом.

Да ну? :)

Оглянитесь. Вне поделок на десктопе такое не допустимо. Автомобили, промышленное оборудование, авиация, и даже банальная водокачка, программ "падальщиков" не потерпят. А ещё удивитесь, что есть ГОСТ'ы, в которых написано, как правильно должно быть, в целом. Более того отдельно оговорено поведение не то что если "переменные испортились", но и если их намеренно испортили.

Логи и дампы можете делать какие угодно, но ошибки надо обрабатывать.

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

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

113. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +/
Сообщение от Аноним (31), 20-Ноя-21, 14:33 
Вы путаете падения релизов с падениями некорректных сборок и падениями дебажных версий -- все эти падения сильно разные.

Падения некорректных сборок неизбежны, но это может быть косяк не только разрабов, но и мантейнеров дистров (со сборкой напортачить могут и те, и другие).

Падения релизов не допустимы -- это косяк разработчиков.

А падения дебажных версий очень полезны -- это процесс разработки.

Так вот тут речь идёт именно о дебажных версиях: если проект серьёзный и ошибку не заметят ни ваши тестеры, ни контрольная группа предзаказчиков, то после поступления продакшн -- когда ошибка проявится и клиентура потеряет деньги/данные/etc. -- проблема у вас будет вне зависимости от обработки ошибки.


Поэтому правило примерно такое:

0. если ошибка возникает внутри кода по вине программистов, она обрабатывается программистами на этапе отладки: отыскивается и устраняется;

1. если ошибка _может_ возникнуть вне кода -- по вине пользователей, админов, etc. -- тогда она обрабатывается: значения проверяются на допустимые, и если они не корректны, то либо выдаётся сообщение об ошибке и работа завершается, либо каким-то образом значения корректируются, либо сбрасываются на предыдущие или дефолтные;

2. если ошибки возможны из-за неверной сборки, то все требования по сборке должны быть правильно описаны, а скриптам сборки следует в должной степени проводить все нужные проверки (задача это сложная, с плясками с бубном и трёхэтажными заклинаниями, косяки тут весьма вероятны).

Ответить | Правка | Наверх | Cообщить модератору

136. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +2 +/
Сообщение от _kp (ok), 20-Ноя-21, 17:58 
> Падения релизов не допустимы -- это косяк разработчиков.

В идеале, но это не значит, что сбои не возникнут, не смотря на все старания и тесты.


> 1. если ошибка _может_ возникнуть вне кода -- по вине пользователей, админов,

а также вредительства и непредвиденного воздействия
(даже без злого умысла пользователь способен  )

> .. значения проверяются на допустимые, и если они не корректны, то либо
> выдаётся сообщение об ошибке

(пишем в лог, сообщаем на сервер поддержки..)

> и работа завершается,

Вам бы для промышленности что то написать, а ещё лучше для авиации. Или просто обдумать работу подобного ПО.

> либо каким-то образом значения корректируются, либо сбрасываются на предыдущие или дефолтные

Так ИНОГДА совсем нельзя. Последствия какие будут?
Операция не отработала, возник сбой, смотрим на что он влияет, оцениваем важность, смотрим сколько у нас времени на реакцию, включаем блокировки, логгируем, действуем согласно ТУ.
А важные значения при передаче еще штампами времени и валидности сопровождают, и фиктивные или устаревшие значения могут быть отброшены в другом модуле, и есть шансы получить ужасные последствия.

Ответить | Правка | Наверх | Cообщить модератору

138. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +/
Сообщение от Аноним (31), 20-Ноя-21, 18:38 
ещё раз: у вас речь идёт о падениях релизов;
речь про core dumped идёт в отношении дебажных версий;


> Так ИНОГДА совсем нельзя. Последствия какие будут?

вот об этом была и речь:

>> Падения релизов не допустимы

Ответить | Правка | Наверх | Cообщить модератору

174. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +/
Сообщение от Урри (ok), 21-Ноя-21, 19:11 
> А падения дебажных версий очень полезны -- это процесс разработки.

Нет.

> Так вот тут речь идёт именно о дебажных версиях: если проект серьёзный
> и ошибку не заметят ни ваши тестеры, ни контрольная группа предзаказчиков,

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

Программа НЕ ДОЛЖНА НИКОГДА падать. Это закон. Любое падение - ЧП и обязано быть рассмотрено в отдельном порядке.

Сходите на полгодика в автомотив поработать, наберетесь неоценимого опыта.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

146. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +/
Сообщение от Прохожий (??), 21-Ноя-21, 01:10 
>Если разработчик может допустить "_любое_" значение в переменных, имеющих конкретный смысл и конкретный спектр принимаемых значений

Ох уж этот мне юношеский максимализм. Давно в профессии? Подозреваю, что год-два, не более, раз такую ахинею несёшь.

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

Отцу русской демократии помогут языки со строгой типизацией. Открой для себя достижения прогресса. Си к таковым, увы, не относится. Это Г давно уже следует похоронить и забыть, как о страшном сне.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

185. "Выпуск ControlFlag 1.0, инструмента для выявления ошибок в к..."  +/
Сообщение от _kp (ok), 21-Ноя-21, 23:28 
> следует похоронить и забыть, как о страшном сне.

Есть такая поговорка, программист на Си может писать на Си на любом языке программирования.

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

Ну бывает, вроде бы и язык новый, а проблемы старые.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру