Комментарии 41
Годнота.
В MISRA 2012 есть 3 уровня правил (обязательные, требуемые и рекомендательные). Есть ли у вас возможность включать отдельные уровни?
В MISRA 2012 есть 3 уровня правил (обязательные, требуемые и рекомендательные). Есть ли у вас возможность включать отдельные уровни?
Интересный инструмент, сейчас используем Tasking для проверки правил Мисры.
Там не всё гладко, чаще всего проблемы возникают с правилом про Side Effect при сравнении условий (13.5)
Там не всё гладко, чаще всего проблемы возникают с правилом про Side Effect при сравнении условий (13.5)
В MISRA нет правил относящихся к стилю. Все правила нацелены на уменьшение количества багов. В приведенном вами примере с if-ом, фигурные скобки нужны вовсе не для красоты, а чтобы защитить от некоторых часто встречающихся ошибок. К примеру, без фигурных скобок, вызов макроса содержащего несколько операторов, сразу после if-а, приведет к ошибке. Такой вызов может быть очень похож на вызов функции и ошибку могут долго не замечать. В MISRA, кстати, есть пояснения почти ко всем правилам. Странно, что вы их не читали. Честно говоря, эта ваша статья очень разочаровывает. Разработчик статического анализатора обязан иметь хотя-бы элементарное понимание стандартов кодирования. В общем-то они все про баги, а не про стиль.
Прозвучало как троллинг, но отвечу. Забавно видеть комментарий «странно, что вы их не читали» после того как стандарты куплены, изучены, реализованы диагностики и по каждой новой диагностике анализатора написана документация на русском и английском языке.
Теперь к сути. Любой стандарт кодирования призван снизить количество ошибок. В том числе для этого предназначены и правила оформления кода. Я и сам часто пишу о том, как тот или иной вариант оформления кода может снизить количество ошибок. Пример: табличное форматирование (подробнее здесь, см. главу 13). Однако MISRA, как и многие другие стандарты, это именно больше про стиль, а не про баги.
Вот, например, диагностика V557 обнаруживает выход за границы массива и выявляет конкретные ошибки. В то время как MISRA C++ диагностика V2517 говорит, что вместо суффикса 'u' надо писать 'U'. Да, это помогает избежать ошибок. С этим никто и не спорит. Однако, подобные правила являются ничем иным как способом писать более простой и понятный код, т.е. стандартом оформления кода.
Так что с «в MISRA нет правил относящихся к стилю» я не согласен. Ещё раз почеркну, что не считаю стилистические правила чем-то плохим. Просто всему своё место.
Теперь к сути. Любой стандарт кодирования призван снизить количество ошибок. В том числе для этого предназначены и правила оформления кода. Я и сам часто пишу о том, как тот или иной вариант оформления кода может снизить количество ошибок. Пример: табличное форматирование (подробнее здесь, см. главу 13). Однако MISRA, как и многие другие стандарты, это именно больше про стиль, а не про баги.
Вот, например, диагностика V557 обнаруживает выход за границы массива и выявляет конкретные ошибки. В то время как MISRA C++ диагностика V2517 говорит, что вместо суффикса 'u' надо писать 'U'. Да, это помогает избежать ошибок. С этим никто и не спорит. Однако, подобные правила являются ничем иным как способом писать более простой и понятный код, т.е. стандартом оформления кода.
Так что с «в MISRA нет правил относящихся к стилю» я не согласен. Ещё раз почеркну, что не считаю стилистические правила чем-то плохим. Просто всему своё место.
Попробую объяснить ещё раз. MISRA определяет как писать код, который изначально содержит меньше багов. А статический анализатор пытается найти баги в уже написаном коде. Это 2 отдельных слоя защиты от багов. Стиль, оформление кода — это ещё одна, 3-я, отдельная сущность. Где ставить пробелы или как делать отступы. Причём, правила стиля не влияют (!) на количество багов сколько-нибудь заметным образом. Влияет соблюдение единого стиля всеми программистами. В MISRA прямо написано, что они не дают рекомендации относящиеся исключительно к стилю. Т.е. вы спорите с стандартом, а не со мной.
Я услышал и понял Вас. Согласен, MISRA это не только стиль и оформление кода. Сказывается, наверное, мое узкое восприятие статического анализа, как методологии поиска ошибок.
Однако, в свою защиту хочу сказать, что MISRA диагностики крайне шумные. Смотришь на 100500 срабатываний и понимаешь, что если рефакторить все эти участки кода, то максимум исправит 3 ошибки. И при этом, если смотреть на «классические предупреждения PVS-Studio», то настоящие ошибки можно исправлять десятками. На фоне этого предупреждение MISRA кажутся незначительными и относящимися скорее к стилю.
P.S. Я понимаю зачем существует MISRA и какую пользу несёт этот стандарт. Однако, этот стандарт надо использовать только при понимании. Иначе, он скорее замедлит и усложнит разработку, не принеся хоть какого-то значимого прироста надёжности и качества.
Однако, в свою защиту хочу сказать, что MISRA диагностики крайне шумные. Смотришь на 100500 срабатываний и понимаешь, что если рефакторить все эти участки кода, то максимум исправит 3 ошибки. И при этом, если смотреть на «классические предупреждения PVS-Studio», то настоящие ошибки можно исправлять десятками. На фоне этого предупреждение MISRA кажутся незначительными и относящимися скорее к стилю.
Собственно, даже в википедии приводятся весьма скептический комментарий :)
From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams' observation that all modifications have a non-zero probability of introducing a fault, this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable.
P.S. Я понимаю зачем существует MISRA и какую пользу несёт этот стандарт. Однако, этот стандарт надо использовать только при понимании. Иначе, он скорее замедлит и усложнит разработку, не принеся хоть какого-то значимого прироста надёжности и качества.
Если меня не подводит память, то в PVS-Studio есть отдельная диагностика, которая должна сработать на такой макрос. В таких условиях отсутствие фигурных скобок — и правда лишь вопрос стиля.
К примеру, без фигурных скобок, вызов макроса содержащего несколько операторов, сразу после if-а, приведет к ошибке.Да, такие ошибки ловятся с помощью V640. С её помощью мы не раз находили интересные ошибки в макросах.
Например:
В GCC :)
V640 The code's operational logic does not correspond with its formatting. The second statement will always be executed. It is possible that curly brackets are missing. asan.c 2582
Или в Tizen
V640 The code's operational logic does not correspond with its formatting. The second statement will always be executed. It is possible that curly brackets are missing. media_codec_port_gst.c 1800
void initialize_sanitizer_builtins (void)
{
....
#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM, \
BUILT_IN_NORMAL, NAME, NULL_TREE); \
set_call_expr_flags (decl, ATTRS); \
set_builtin_decl (ENUM, decl, true);
#include "sanitizer.def"
if ((flag_sanitize & SANITIZE_OBJECT_SIZE)
&& !builtin_decl_implicit_p (BUILT_IN_OBJECT_SIZE))
DEF_SANITIZER_BUILTIN (BUILT_IN_OBJECT_SIZE, "object_size",
BT_FN_SIZE_CONST_PTR_INT,
ATTR_PURE_NOTHROW_LEAF_LIST)
....
}V640 The code's operational logic does not correspond with its formatting. The second statement will always be executed. It is possible that curly brackets are missing. asan.c 2582
Или в Tizen
#define MC_FREEIF(x) \
if (x) \
g_free(x); \
x = NULL;
static gboolean __mc_gst_init_gstreamer()
{
....
int i = 0;
....
for (i = 0; i < arg_count; i++)
MC_FREEIF(argv2[i]);
....
}V640 The code's operational logic does not correspond with its formatting. The second statement will always be executed. It is possible that curly brackets are missing. media_codec_port_gst.c 1800
Неожиданно узнал что PVS умеет в Embedded…
А совсем жёсткий Embedded — microchip xc семейство C-подобных компиляторов планируется?
На TI Code Composer Studio проектах обязательно поробую, когда будет больше свободного времени.
А совсем жёсткий Embedded — microchip xc семейство C-подобных компиляторов планируется?
На TI Code Composer Studio проектах обязательно поробую, когда будет больше свободного времени.
А совсем жёсткий Embedded — microchip xc семейство C-подобных компиляторов планируется?Скорее всего, нет. Но если выстроится очередь из нескольких потенциальных клиентов, то это другое дело :).
Очень хотелось бы чтобы вы добавили поддержку CCES от Analog Device. По идее там не сложно ибо это Eclipse, но «вручную» это делать без «встроенной» поддержки со стороны анализатора я, например, точно не буду.
Всё что у меня разрабатывается в Visual Studio и лишь портировано в Embedded там всё покрыто и тестами и отпрофилировано алгоритмически и PVS по своим проектам пройдено. Но вот в самих железках тьма ужасного и плохо работающего кода в SDK, драйверах и много где ещё и хоть и приходится его «патчить» чтобы работало не так уныло и не глючило, но качество всё равно оставляет желать лучшего.
Всё что у меня разрабатывается в Visual Studio и лишь портировано в Embedded там всё покрыто и тестами и отпрофилировано алгоритмически и PVS по своим проектам пройдено. Но вот в самих железках тьма ужасного и плохо работающего кода в SDK, драйверах и много где ещё и хоть и приходится его «патчить» чтобы работало не так уныло и не глючило, но качество всё равно оставляет желать лучшего.
> Очень хотелось бы чтобы вы добавили поддержку CCES от Analog Device.
Первый раз слышу. Понятно, что у меня узкий кругозор в этой теме, но реально похожи никто до сих пор не упоминал нам такую вещь.
Кстати тут видимо два вопроса в одном: поддержка компилятора и поддержка IDE? Может оказаться, что компилятор мы уже и так поддерживаем. А для специализированной IDE плагин делать не в плане, так как слишком мало пользователей.
Первый раз слышу. Понятно, что у меня узкий кругозор в этой теме, но реально похожи никто до сих пор не упоминал нам такую вещь.
Кстати тут видимо два вопроса в одном: поддержка компилятора и поддержка IDE? Может оказаться, что компилятор мы уже и так поддерживаем. А для специализированной IDE плагин делать не в плане, так как слишком мало пользователей.
У меня тоже кругозор не сильно широкий в этой области ибо я не разрабатываю напрямую под Embedded, но иногда приходится «погружаться», а там лютый биоразложимый код не покрытый тестами и дико забагованный уже на уровне идущего в комплекте SDK. Собственно под этой средой я только прошивки собираю, отлаживать в железе что либо там всё равно невозможно ибо каждый шаг в отладчике это ~10 секунд и код не лету править невозможно, хотя в железке ARM ядро не очень древнее.
Нужна поддержка, разумеется, только компилятора, поддерживать IDE смысла не имеет никакого ибо это какой то испорченный нестандартный Eclipse. По всей видимости Analog Device это компания «железячников» которая до сих пор не поняла что их куски кремния без ПО и хорошего SDK никому не нужны.
P.S. компания на которую сейчас работаю использует «это» лишь потому что продукт поставляется российским военным, а в списках железа которое можно использовать «это» фактически лучшее что есть, ну а внести туда что то реально хорошее маленькой компании невозможно ибо адовая бюрократия и многомиллионные откаты на это требуются.
P.P.S. прошу прощения за крик души :'(
Нужна поддержка, разумеется, только компилятора, поддерживать IDE смысла не имеет никакого ибо это какой то испорченный нестандартный Eclipse. По всей видимости Anal
P.S. компания на которую сейчас работаю использует «это» лишь потому что продукт поставляется российским военным, а в списках железа которое можно использовать «это» фактически лучшее что есть, ну а внести туда что то реально хорошее маленькой компании невозможно ибо адовая бюрократия и многомиллионные откаты на это требуются.
P.P.S. прошу прощения за крик души :'(
Скачал демо-версию, проверил в Keil, возник вопрос.
У меня в проекте используется автомат состояний.
Переменной присваивается какое-то значение, в зависимости от ее значения выполняются те или иные действия.
При проверке в PVS-Studio, обнаружил. что во-первых, не проверяются возможные значения этой переменной, во-вторых, не проверяется, есть ли «мертый код», то есть такой, куда я никогда не попаду, так как для попадания в этот участок кода переменная никогда не примет нужное значение.
Пример:
или
Так и должно быть?
У меня в проекте используется автомат состояний.
Переменной присваивается какое-то значение, в зависимости от ее значения выполняются те или иные действия.
При проверке в PVS-Studio, обнаружил. что во-первых, не проверяются возможные значения этой переменной, во-вторых, не проверяется, есть ли «мертый код», то есть такой, куда я никогда не попаду, так как для попадания в этот участок кода переменная никогда не примет нужное значение.
Пример:
if (state == 1)
{state = 2;}
else if (state == 2)
{state = 1;}
else if (state == 3) // Сюда никогда не попадем
{state = 2}
или
if (state == 1)
{state = 2;}
else if (state == 2)
{state = 3;}
else if (state == 3)
{state = 155;} // Неверное значение
Так и должно быть?
Недостаточно информации для ответа. Если переменная может меняться ещё где-то, то анализатор видимо не может отследить её возможные состояния. Прошу привести законченный минимальный пример функции, где нет срабатывания. Если хотите, можно перенести обсуждение в почту.
Попробую накидать пример.
Пример использования автомата состояния
// Файл main.c
int main()
{
....
while(1)
{ Work(); }
}
// Файл Work.c
uint8_t state = 0;
void Work()
{
if (state != 0)
{
Control();
}
if (state != 0)
{
if (error_1 == 1 || state == 1)
{
if (state != 1)
{
state = 1;
}
}
else if (error_2 == 1 || state == 2 || state == 3 || state == 4)
{
if (state != 2 && state != 3 && state != 4)
{
state = 2;
}
}
}
switch(state)
{
case 0:
...
state = 1;
break;
case 1:
...
state = 2;
break;
case 2:
...
state = 3;
break;
case 3:
...
state = 4;
break;
case 4:
...
state = 85; // Неверное значение (опечатка)
break;
case 5:
...
state = 1; // Вот сюда никогда не попадем
break;
}
}
// файл Control.c
extern uint8_t state;
void COntrol()
{
if (state == 3)
{
// Вывод сообщения о ситуации
}
}
К сожалению, для статических анализаторов, подобный код очень сложен. В том числе и для PVS-Studio. Отслеживать значение глобальных переменных, это неблагодарное дело и делается только в простых случаях :).
P.S. Если кому-то интересно чуть подробнее узнать, как работает вычисление значений в PVS-Studio, то предлагаю познакомиться с докладом "Как работает анализ Data Flow в статическом анализаторе кода".
P.S. Если кому-то интересно чуть подробнее узнать, как работает вычисление значений в PVS-Studio, то предлагаю познакомиться с докладом "Как работает анализ Data Flow в статическом анализаторе кода".
После выбора проверки текущего файла:
Сорри, не знал как убить случайно отправленный комент…
Так вот
Не понимает что пишу на Си?
Проект для ESP32
Скриншот VS2017
Не понимает что пишу на Си?
Проект для ESP32
Правильно я понимаю, что Вы просто открыли файл и попытались его проверить?
Так не получится. В отличии, например, от Cppcheck, анализатор PVS-Studio работает не на регулярных выражениях и должен обладать полной информацией о том, как файл компилируется. Это необходимо, чтобы найти заголовочные файлы, узнать как раскрываются макросы и т.д. Вам нужно создать полноценный компилируемый проект для Visual Studio. Если это сложно, то просто компилируйте файл любым способом и собирайте информацию о ключах запуска компилятора с помощью утилиту PVS-Studio Standalone (см. раздел "Анализ исходных файлов с помощью отслеживания запуска компиляторов"). Аналогичная утилита есть и для Linux.
Так не получится. В отличии, например, от Cppcheck, анализатор PVS-Studio работает не на регулярных выражениях и должен обладать полной информацией о том, как файл компилируется. Это необходимо, чтобы найти заголовочные файлы, узнать как раскрываются макросы и т.д. Вам нужно создать полноценный компилируемый проект для Visual Studio. Если это сложно, то просто компилируйте файл любым способом и собирайте информацию о ключах запуска компилятора с помощью утилиту PVS-Studio Standalone (см. раздел "Анализ исходных файлов с помощью отслеживания запуска компиляторов"). Аналогичная утилита есть и для Linux.
Как-то слабовато у вас с покрытием не то, что всех правил, но даже правил уровня required. То, что поддерживается, выглядит как простой способ отметиться в теме, не более того. MISRA используются не для отмашки типа «ну да, что-то проверили», а для того, чтобы показать, что написанный код более безопасен и легче в поддержке, чем код, этим правилам не соответствующий.
Стыдно должно быть за такие заявления, как «PVS-Studio: поддержка стандартов кодирования MISRA C и MISRA C++». Не поддерживаете вы этот стандарт. Вообще никак. И использовать ваш тул для работы по этому стандарту нельзя. Потому что выхлоп от него — минимальный. И из-за этого ваш тул больше навредит, чем поможет.
Стыдно должно быть за такие заявления, как «PVS-Studio: поддержка стандартов кодирования MISRA C и MISRA C++». Не поддерживаете вы этот стандарт. Вообще никак. И использовать ваш тул для работы по этому стандарту нельзя. Потому что выхлоп от него — минимальный. И из-за этого ваш тул больше навредит, чем поможет.
Из общения на конференциях мы знаем, что информация распространяется очень медленно. В этом году мы посетили множество конференций и для многих из подходивших к стенду стало открытием, что у нас появилась поддержка C# или Linux. К тому моменту, когда хоть кто-то узнает что мы поддерживаем MISRA мы серьезно продвинемся в её поддержке. Но начинать писать надо уже сейчас. :)
Мы и не говорим, что полностью поддерживаем MISRA. Впрочем, этот стандарт никто полностью никто не поддерживает, что не мешает писать про поддержку :). Это первая версия анализатора, где мы начали добавлять MISRA диагностики. В следующей версии появятся новые диагностики и т.д. Думаю мы достаточно быстро продвинемся в этом направлении и сделаем хорошее покрытие.
Мы и не говорим, что полностью поддерживаем MISRA. Впрочем, этот стандарт никто полностью никто не поддерживает, что не мешает писать про поддержку :). Это первая версия анализатора, где мы начали добавлять MISRA диагностики. В следующей версии появятся новые диагностики и т.д. Думаю мы достаточно быстро продвинемся в этом направлении и сделаем хорошее покрытие.
Офф-топ: я так понимаю, вы тут друг-другу плюсики ставите?
Обратно к теме: от повторения фразы «мы поддерживаем MISRA» поддержка MISRA не появится. Это этика бизнеса, и она у вас, как правописание у Винни Пуха, хромает. Причем на обе ноги. В статье вы говорите о поддержке, как о случившемся факте. Это вранье. Примите это, и не повторяйте таких ошибок в будущем.
Обратно к теме: от повторения фразы «мы поддерживаем MISRA» поддержка MISRA не появится. Это этика бизнеса, и она у вас, как правописание у Винни Пуха, хромает. Причем на обе ноги. В статье вы говорите о поддержке, как о случившемся факте. Это вранье. Примите это, и не повторяйте таких ошибок в будущем.
За время развития PVS-Studio хорошо себя зарекомендовала следующая практика. Реализуется какая-то фича. Потом мы находим клиентов, которым нужны те или иные новые компоненты анализатора (диагностики, инструментальные средства, возможности по интеграции). И уже доделываем непосредственно под них. Это позволяет клиентам быстро получать то, что нужно им. В противном случае, выбирая для реализации фичи/диагностики случайным образом, мы будем идти до клиента очень долго.
Поэтому если у вас есть интерес к этой теме – давайте вместе сделаем анализатор такой как нужно именно вам. Т.е. напишите список диагностик MISRA которые вы применяете или планируете применять в своей работе. Мы их реализуем и порадуем вас :). А потом уже займёмся прочими диагностиками.
Поэтому если у вас есть интерес к этой теме – давайте вместе сделаем анализатор такой как нужно именно вам. Т.е. напишите список диагностик MISRA которые вы применяете или планируете применять в своей работе. Мы их реализуем и порадуем вас :). А потом уже займёмся прочими диагностиками.
Евгений, если говорить о поддержке стандарта, то как минимум ВСЕ обязательные требования (именно обязательные!) должны поддерживаться по умолчанию. Остальное — обсуждаемо, согласен.
Судя по комментариям выше — у вас есть полный текст этого стандарта. Этот стандарт содержит список диагностик MISRA, которые мы применяем или планируем применять в своей работе. Будет здорово, если ваш инструмент начнет поддерживать требования уровня REQUIRED в полном объеме. Спасибо.
Судя по комментариям выше — у вас есть полный текст этого стандарта. Этот стандарт содержит список диагностик MISRA, которые мы применяем или планируем применять в своей работе. Будет здорово, если ваш инструмент начнет поддерживать требования уровня REQUIRED в полном объеме. Спасибо.
Основная проблема в том, что они не понимают, зачем MISRA вообще нужна! Более того, в ответе на мои комментарии выше (я пытался объяснить), автор пишет: «Я услышал и понял Вас. Согласен, MISRA это не только стиль и оформление кода.» Хотя я написал, что в MISRA вообще нет правил посвящённых стилю! Выходит, что автор таки не слышит. (И выходит, не желает понять.)
Далее он приводит цитату из Википедии с критикой MISRA. Я прочитал работу, из которой она взята. К сожалению, там используется тот-же ошибочный взгляд на MISRA, что и у автора этой статьи. Что к правилам MISRA можно применять тот-же критерий качества, что и к предупреждениям статического анализатра. Т.е. отношение количества истинных багов и ложных срабатываний. (В той работе взят код, написанный без соблюдения MISRA и показаны «ужасные» 7000 нарушений MISRA при наличии всего пары десятков реальных багов.)
Уважаемый Andrey2008! Правила MISRA придуманы для соблюдения их людьми. Такие правила придумать намного сложнее, чем алгоритмы статического анализатора. Анализатор, например, имеет ряд алгоритмов находящих утечки памяти, а человеку бесполезно говорить: «всегда освобождай память выделенную в куче». Глупо проверять произвольно взятый код на соблюдение MISRA. Код должен изначально писаться под MISRA!
Ещё автор пишет, что «никто полностью не поддерживает MISRA». Естественно! В самом стандарте правила делятся на decideable, которые могут быть проверены статическим анализатором и undecideable, которые не могут или могут, но не всегда. Поэтому не может быть написан такой анализатор, который проверяет все правила. В принципе не может!
В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта. Но я как-то полагал, что уж кто-кто, а разработчики статик-аналайзера в этом эксперты. Извините господа, но вы спалились…
Далее он приводит цитату из Википедии с критикой MISRA. Я прочитал работу, из которой она взята. К сожалению, там используется тот-же ошибочный взгляд на MISRA, что и у автора этой статьи. Что к правилам MISRA можно применять тот-же критерий качества, что и к предупреждениям статического анализатра. Т.е. отношение количества истинных багов и ложных срабатываний. (В той работе взят код, написанный без соблюдения MISRA и показаны «ужасные» 7000 нарушений MISRA при наличии всего пары десятков реальных багов.)
Уважаемый Andrey2008! Правила MISRA придуманы для соблюдения их людьми. Такие правила придумать намного сложнее, чем алгоритмы статического анализатора. Анализатор, например, имеет ряд алгоритмов находящих утечки памяти, а человеку бесполезно говорить: «всегда освобождай память выделенную в куче». Глупо проверять произвольно взятый код на соблюдение MISRA. Код должен изначально писаться под MISRA!
Ещё автор пишет, что «никто полностью не поддерживает MISRA». Естественно! В самом стандарте правила делятся на decideable, которые могут быть проверены статическим анализатором и undecideable, которые не могут или могут, но не всегда. Поэтому не может быть написан такой анализатор, который проверяет все правила. В принципе не может!
В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта. Но я как-то полагал, что уж кто-кто, а разработчики статик-аналайзера в этом эксперты. Извините господа, но вы спалились…
Здравствуйте, спасибо за подробные комментарии.
> Основная проблема в том, что они не понимают, зачем MISRA вообще нужна!
Расскажите нам, что мы должны реализовать, чтобы вы стали нашим клиентом? Как я писал выше, намного продуктивнее делать что-то под конкретного клиента.
> В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта.
Давайте напишем совместную статью про это? Ваш взляд и наш? Можно в форме интервью. Все пользая будет!
> Основная проблема в том, что они не понимают, зачем MISRA вообще нужна!
Расскажите нам, что мы должны реализовать, чтобы вы стали нашим клиентом? Как я писал выше, намного продуктивнее делать что-то под конкретного клиента.
> В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта.
Давайте напишем совместную статью про это? Ваш взляд и наш? Можно в форме интервью. Все пользая будет!
Боюсь, от этого не будет никакой пользы… Как раз одна из моих будущих задач на работе — выбрать статик аналайзер и Мисра-чекер. Причём нам не нужен полный Мисра-чекер прямо сейчас, т.к. внедрены только некоторые из правил Мисры. Т.е. они внедрены для внутреннего употребления. Мы не можем заявлять, что как-то соответсвуем Мисре. Выходило, что ваш функционал именно то, что нужно! Поэтому-то я вдвойне заинтересовался этой статьей. Думал, что узнаю что-нибудь новое. Мои знания в этой области сейчас фрагментарны — что-то знаю глубоко, что-то поверхностно. Но, как я писал, увы, статья меня расстроила. Если-бы было написано, что вы частично имплементировали поддержку Мисры, без всяких теоретических рассуждений, то я-бы подумал ОК, вернусь к вашей программе по-позже, когда вплотную займусь выбором аналайзера. Но именно из за этой статьи моё мнение о PVS-Studio поменялось к худшему. Так-что выходит, что вашим клиентом моя компания не станет. И статью я не потяну написать т.к. не чувствую за собой достаточный багаж знаний. Для статьи надо понимать объективную причину для каждого правила, до чего мне ещё далеко. Кроме того, знания о стандартах более высокого уровня (типа DO-178 и IEC-61508) у меня совсем поверхностные. Такие вот дела… Звыняте :-(
Вышел обзор анализатора PVS-Studio с точки зрения разработки встраиваемых систем и поддержки стандарта MISRA C: PVS-Studio & KEIL 5 (STM32CubeMX) совместная работа.
Аннотация и комментарии
Аннотация автора:
Данное видео продолжает серию обзоров. В нём мы научимся использовать статический анализатор кода PVS-Studio совместно с интегрированной средой разработок KEIL 5 с применением генератора кода STM32CubeMX на практике и увидим, как нам это может упростить процесс разработки встраиваемых систем.
Обзор нам понравился, и мы выражаем признательность автору. Спасибо ему за проделанную работу.
Несколько комментариев:
Иногда анализатор указывал на функции, в которых был виден только один оператор return. И было непонятно, почему PVS-Studio предупреждает о множественных return. Чтобы их найти, нужно заглянуть в макросы, используемые в функции. Какой-то из макросов содержит в себе оператор return.
Стандарт MISRA весьма педантичен и противоречив. На практике полностью удовлетворить ему невозможно. Например, невозможно не использовать union, если нужен этот самый union :). Диагностики MISRA делятся на 3 уровня: Required (требуемые/обязательные к правке), Advisory (рекомендуемые), Document (информационные предупреждения). Поэтому, когда говорят, что поддерживается MISRA, имеется в виду, что нет предупреждений типа Required (в PVS-Studio это предупреждения уровня High). Именно такую картину мы и видим в процессе проверки проекта. Нет ни одного предупреждения уровня High, т.е. нет предупреждений, обязательных к устранению. Так что действительно можно подтвердить, что проверенный проект советует стандарту MISRA C.
Данное видео продолжает серию обзоров. В нём мы научимся использовать статический анализатор кода PVS-Studio совместно с интегрированной средой разработок KEIL 5 с применением генератора кода STM32CubeMX на практике и увидим, как нам это может упростить процесс разработки встраиваемых систем.
Обзор нам понравился, и мы выражаем признательность автору. Спасибо ему за проделанную работу.
Несколько комментариев:
Иногда анализатор указывал на функции, в которых был виден только один оператор return. И было непонятно, почему PVS-Studio предупреждает о множественных return. Чтобы их найти, нужно заглянуть в макросы, используемые в функции. Какой-то из макросов содержит в себе оператор return.
Стандарт MISRA весьма педантичен и противоречив. На практике полностью удовлетворить ему невозможно. Например, невозможно не использовать union, если нужен этот самый union :). Диагностики MISRA делятся на 3 уровня: Required (требуемые/обязательные к правке), Advisory (рекомендуемые), Document (информационные предупреждения). Поэтому, когда говорят, что поддерживается MISRA, имеется в виду, что нет предупреждений типа Required (в PVS-Studio это предупреждения уровня High). Именно такую картину мы и видим в процессе проверки проекта. Нет ни одного предупреждения уровня High, т.е. нет предупреждений, обязательных к устранению. Так что действительно можно подтвердить, что проверенный проект советует стандарту MISRA C.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PVS-Studio: поддержка стандартов кодирования MISRA C и MISRA C++