Средства и методы разработки

Можно подумать, automotive софт это такая священная корова, где всё не так, как во всём остальном мире. Где существует и гораздо более сложный, и гораздо более ответственные применения. Нет никаких проблем с стандарными типами на 16-битных платформах ещё со времён DEC и оригинального unix, откуда собственно C и пошёл. (назови какие). Есть только проблема портирования 32 -> 16 бит для некачественного кода (когда неявно предполагают sizeof(int)>=sizeof(void*) и MAX_INT >> 1000000000). Но если речь по большей части о собственном коде и C библиотеке, то проблем нет. "Компиляторы могут быть косые и кривые". Атас. После этого они декларируют за высокую надёжность софта. Если такие умные -- делайте на AVR'ках и ARM'ах. Там есть GNU ADA. С такими правилами и проверками надёжности кода, что ваша MISRA и рядом не стояла. И вместо покупки индусского говнокода можно договориться с разработчиками GCC и создании бэкпорта для нужного процессора. Но на этом же не заработаешь денег, и MISRA внакладе останется, только потратишь на зряплату программистишкам (вот и вся бизнес идея этой мисры). Наконец есть трансляторы Pascal-->C, интерпретаторы ЯВУ. Зачем биться головой об лёд пытаясь на языке предназначенном для системного программирования (C), и позволяющем массу грязных хаков потому, что-то программировать "высоконадёжное", когда есть более специалиированные языки. Да тот же Pascal. В нём нет goto и массы других вещей. И вместо varargs есть оператор (не функция) write. Нет static и макросов. Но есть интерфейсы и вложенные процедуры. Нет опасных хаков, но есть более безопасные способы сделать что-то подобное. Зачем тогда C??? В ADA вон сопрограммы есть. Для управляющих программ, характеризующихся сильным параллелизмом -- самое то. Всяко лучше недо ОС для C. Есть ADA to C трансляторы. ADA разрабатывался как специальный язык для высоконадёжного ПО. Зачем MISRA? Зачем создавать себе проблемы некачественными средствами разработки и делать вид, что MISRA эти проблемы решает (решает, но далеко не все же). Ответ я знаю -- тогда не будет модного слова MISRA, а будет ADA, которой никого уже не вдохновишь. Ну как PL/M, например, или Pascal. Совершенно не вызывает впечатления. Можно ещё придумать какое-нибудь своё слово, АБВГД-технология. Тоже будет звучать и продаваться, если менагеры постараются. "полностью полагаться на его warning-и нельзя" -- а полагаться на варнинги MISRA можно? Она лучше компилятора знает (компилятор знает конктекст в котором, а MISRA тупо проверяет по шаблону). Чем одна программа лучше другой? Да и помимо MISRA-checker'ов есть полно софта для статического анализа, получше MISRA будет. Вон PVS-studio, например. MISRA здесь не является чем-то уникальным. Можно внутри фирмы решить какие практики опасны, а какие нет, для конкретного проекта, и использовать в файле конфигурации для статического анализатора. "То же самое про отлаженные библиотечные функции." -- т.е. ты утверждаешь, что лучше написать свои. Не написать тесты на библиотечные функции, если есть к ним вопросы. А написать свои. И сколько на это нужно потратить в процентах от проекта? (не, я понимаю, что в больших проектах есть такая же своя большая библиотека и там есть часто возможность перекрыть часть библиотечных функций на некоторых платформах...) На разработку, на документирование, на тестирование, на отладку, на последующую поддержку? Это идёт сильно вразрез с коммерческим программированием. Ибо бюджет не резиновый. Стандартная библиотека это всё-же тысячи строк и человекогоды на разработку. "Все это накладывается на разную квалификацию программистов в команде. Сжигать студентов нельзя..." -- ну вот и вся подноготная мисры раскрылась. Что сразу и было видно. Сэкономим на зряплате программистам, наймём мальчиков-штрехбрейкеров с мамой папой и квартиркой, родим феерической говнокод и прикроем жопу бумажкой с мисрой. MISRA -- сжигать. Чтоб не сжигать студентов нужно code review делать.