СИ-код. Увеличение безопасности кода.

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

Код (Text):

1. *p + 1
2. p + 1
3. и т.п.

Тогда можно ввести интерфейс - некоторую функцию для данных, но их много и они самые разные (от байтов до структур с битовыми полями).

Спасибо.

 

Имеется ввиду безопасность кода с точки зрения подачи на вход ложной информации? Или просто кодирование без возможности сделать ошибку по невнимательности?

 

не писать на Си

 

Под безопасностью кода подразумевается мной в данном случае три компоненты:
1. Возможные ошибки программиста при вводе им символов.
2. Возможные ошибки при использовании любых механизмов.
3. Любые аппаратные ошибки (искажение памяти и т. п.).

 

GoldFinch

Согласен, но я не имею сейчас возможности менять язык. Даже C99 нельзя.

 

NoName
если у вас msvc включите там статический анализ
также помогает компиляция с максимум предупреждений

 

GoldFinch
Для статического анализа применяю PCLint 9 который на мой взгляд гораздо лучше и не зависит от среды разработки.
Нужно предсмотреть именно архитектуру построения программ на уровне исходного кода такой чтобы она была максимально безопасной.

 

Ну у вас и запросы.

1. Придерживаться правил для языка.
a). Обязательная инициализация локальных переменных и отслеживания их освобождения.
б) Обязательная проверка внешних данных. К примеру при чтение из файла. А также проверка входных данных в каждую процедуру.
в) Использование ООП и шаблонов
г) Использование тестовых юнитов.
д) Включить отслеживание ошибок, предупреждений и так далее. И прислушиваться им в полном объеме. По возможности.

2. Про любые не скажу.
а) Обработка исключений try except Finale
б) процедуры для автоконтроля состояния.
в) Автоматический сборщик мусора. Для отслеживания утечик.
г) Предусмотреть механизмы восстановления.
д) Использование модель проектирования разделяющие ввод и обработку. По хорошему они должны быть в разных потоках. К примеру http://ru.wikipedia.org/wiki/Model-View-Controller

3. Тут трудно что то придумать. Вести логи и после перепроверять их на корректность.

 

Pavia
ООП нельзя из-за того что нужно разделение на RAM и ROM области.
Механизмы восстановления интересны, но пока не используются (делается более простая система с перезагрузкой ПО).

Пункт 2.б интересно, но что конкретно?

Система должна работать долгое время полностью автономно.

 

NoName
бейте на блоки с жестко определенными интерфейсами. в интерфейсах предусмотрите все сверки и восстановления чтоб ошибки не бродили между блоками. каждый блок хорошо проверяйте-отлаживайте отдельно.

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

тогда вам даже вынь не подойдет.

може вам двинуть в сторону модулы и выше? они как раз для такого и задумывались.

 

Дублировать аппаратуру. Спутники работают в течении 5-10 лет за счёт трех кратного дублирования.

 

Эта идея вполне очевидна. Вопросы касаются ПО.

 

вот тут я не понял каким образом мешает ООП? =)

По теме есть куча книг по безопасному программированию на С. Под безопасностью подразумевается сведение к минимуму потенциально глючных и баго-опасных участков кода, т.е. уход от error prone кода. В общих чертах, это набор вполне очевидных правил программирования, который иногда называется культурой программирования, методологией, паттернами (в ООП) и прочее и прочее.

 

так вот что ТС имел ввиду под "безопасностью кода" =)))

1. Метод "защиты от дураков". Ничего эффективнее и проще нет.
2. Каких таких механизмов? =)
3. _Любые_ аппаратные ошибки не обработать. По самому этому определению =)))

Вообще вопросы из области "хочу чего-то, а чего именно не знаю, давайте по болтаем о вечном" =)))
Впрочем в Wasm.Heap все можно =)

 

C++ компиляторы делают динамическое связывание и подобные вещи которые запрещены для увеличения безопасности кода. В области где я работаю разрешен только borland С 4.5 (мне ОЧЕНЬ это ненравится, но таковы требования). Он считается провереным (хотя были приколы уже с ним разного рода неоднократно, потом напишу может быть какие). Безопасность любых других компиляторов нужно доказывать, что почти нереально (я живу в РФ).

 

NoName

??

 

Таблицы виртуальных функций.

 

NoName
Не использовать виртуальные функции? если они не нужны, то их можно не использовать, если вам нужен подобный механизм, тот тут 2 варианта, либо компилятор либо ручками сделать тоже самое.

 

spa
Дело в том что таких причин была группа. Мне сложно сейчас перечислить все. Еще было что-то связанное тоже с ROM.
У нас, например, в си запрещены статические переменные в функциях.
Был интересный случай с кодогенерацией switch - переходы на адресах в данных при наличии больше N case. Пришлось адаптировать архитектуру защищенного режима вместо смены компилятора на нормальный.

 

NoName

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

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

В данном случае полагаю речь идет о чем-то пускаемом в полет типа проги на спутнике. Даже при стандарте одна ошибка на 10^4 строк кода всегда есть риск отказа. Поэтому маленький независимый диспетчер который в случае практически любого фолта "выйдет на связь" и сможет позволить удаленно перезалить глючный модуль/выслать крэшдамп по телеметрии/удаленно пропатчить обнаруженный баг будет более надежным решением нежели только многократные попытки обнаружить все-все баги.

Да, и этап тестирования может быть даже более важен чем выбор "надежной стратегии программирования".