Обсуждение "The Power of 10: Rules for Developing Safety-Critical Code"

[RXL]

The Power of 10: Rules for Developing Safety-Critical Code.

Они призывают не пользоваться макросами. Но те же стандартные библиотеки Си (например, glibc) прямо кишат ими. Этого они не боятся?

[Dale]

Там, в правиле 8, не настолько прямолинейный запрет:

The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed.

Призывают поменьше злоупотреблять условной компиляцией (ограничиться одной-двумя директивами) и не разводить многоуровневые подстановки, которые самому автору будут непонятны через неделю. А вообще бояться макросов - на C не писать, полный запрет сделает и без того не слишком богатый язык вообще непригодным для написания реально полезного кода.

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

[Sla]

Некоторые из них откровенно банальны (вроде моратория на использование goto);

Да, но это ему под руку попалось
Но он еще говорит и о setjmp и longjmp, а также о прямой и косвенной рекурсии, что для Встраиваемых систем очень актуально.

[Dale]

он еще говорит и о setjmp и longjmp

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

а также о прямой и косвенной рекурсии, что для Встраиваемых систем очень актуально.

Здесь согласен на 100%, очень дельная рекомендация. Рекурсия, конечно, божественна, но, обладая куцым стеком, в рекурсию лучше даже и не соваться.

[Sla]

запрет использования указателей на функции

Я б не сказал, что запрещает.
Не рекомендует. 

указатели на функции могут быть использованы только при очень сильном обосновании, причина -  они могут серьезно ограничить автоматизированное тестирование

[Dale]

запрет использования указателей на функции

Я б не сказал, что запрещает.
Не рекомендует.

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

Function pointers are not permitted.

Нельзя - и точка. Потом в обосновании намек, что если нельзя, но очень хочется, то все-таки можно.

...function pointers should be used only if there is a very strong justification for doing so...

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

Но мы все-таки пишем код не для того, чтобы угодить статическому анализатору, а для того, чтобы эффективно и безопасно решить задачу, так что я бы не стал отказываться от столь мощного инструмента лишь на том основании, что его контроль не по зубам современным анализаторам. Жертвовать ради этого паттернами типа Strategy или Template Method лично для меня - непозволительная роскошь.

[Dimka]

Правило 1 запрещает рекурсию. Это мне непонятно. Проблема может быть в переполнении стека. Но если алгоритм преобразовать в циклический, всё равно может быть проблема переполнения счётчика. Разумнее запрещать не рекурсию, а запуск из рекурсивных функций каких-то длинных обработок, потенциально способных привести к повторному запуску рекурсии, в условиях, когда не случился полный возврат из предыдущего запуска. Однако любые алгоритмы древовидного перебора гораздо удобнее решать рекурсивно, иначе придётся эмулировать стек вручную. Если же говорить о проблеме отсутствия fixed point, т.е. возникновении бесконечной рекурсии или бесконечного цикла, то данное правило никак не помогает предотвратить такую ошибку. Скорее её помогает предотвратить второе правило.

[RXL]

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

[Sla]

Dimka, разговор идет о контроллерах, в основном, с ограниченными возможностями (статья от 2006 года). А возможности ограничены размером ОЗУ, размером стека. Впрочем, и сейчас, это не снимает актуальности. Если все же есть необходимость рекурсии, то нужно четко просчитывать ее уровень вложенности. А бегать по дереву в контроллерах - ну... надо поискать такие задачи.

[Dale]

разговор идет о контроллерах, в основном, с ограниченными возможностями (статья от 2006 года). А возможности ограничены размером ОЗУ, размером стека. Впрочем, и сейчас, это не снимает актуальности.

Сегодня, 6 лет спустя, тоже выпускаются контроллеры с весьма скромными ресурсами памяти: для PIC - от 16 байт, для AVR - от 32 байт. При таких ресурсах говорить о рекурсии просто смешно, после определения нескольких переменных едва останется достаточно места для пары-тройки вложенных вызовов (не говоря уже об обработке прерываний). Впрочем, у старших моделей 8-разрядных контроллеров встроенная RAM редко превышает 4 Кбайт, тоже особо не разгуляешься.