PVS-Studio: поддержка стандартов кодирования MISRA C и MISRA C++

    PVS-Studio, MISRA C, MISRA C++

    Начиная с версии 6.27 статический анализатор кода PVS-Studio может классифицировать свои предупреждения согласно стандартам MISRA C и MISRA C++. Благодаря поддержке этих стандартов анализатор стало возможным эффективно использовать для улучшения безопасности, переносимости и надежности программ для встраиваемых систем.

    В этом году мы занялись поддержкой в анализаторе PVS-Studio таких стандартов, как CWE и SEI CERT. В основном поддержка свелась к классификации уже реализованных в анализаторе диагностик согласно этим стандартам. Дополнительно было реализовано несколько новых или расширено несколько старых диагностик, чтобы более полно соответствовать этим стандартам.

    Таблицы соответствий диагностик PVS-Studio различным стандартам:


    Теперь настало время стандартов MISRA C и MISRA C++. Это стандарты разработки программного обеспечения на языке C и C++, созданные организацией MISRA (Motor Industry Software Reliability Association). Цель стандартов — улучшить безопасность, переносимость и надежность программ для встраиваемых систем. Текст стандартов является платным.

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

    Многие анализаторы идут по другому пути и реализуют диагностики, связанные со стандартами кодирования. Они подсказывают, как лучше именовать переменные, напоминают вставлять комментарии в начало файла и так далее. Это нужно и полезно. Однако в этом случае анализаторы очень «шумные» и генерируют огромное число предупреждений, в которых тонут предупреждения, касающиеся ошибок.

    Мы решили, что PVS-Studio будет анализатором, который ищет именно ошибки. Это его конкурентное преимущество. Программист может запустить его на большой кодовой базе и быть уверен, что его не завалит невероятным количеством сообщений про оформление кода и он сможет сосредоточиться именно на багах.

    Поэтому мы изначально критически относились к стандартам MISRA и долгое время не планировали их реализовывать. Стандарты MISRA предназначены для упрощения и улучшения качества кода в целом, что помогает предотвращать ошибки. То есть в нем как раз большинство диагностик относится к стилю написания кода. Лучше всего это пояснить на примере.

    В стандарте MISRA есть правило, согласно которому тела операторов if должны быть заключены в фигурные скоки. В MISRA C это правило 15.6, а в MISRA C++ это 6-4-1. Пример неправильного кода:

    if (i == bestOffs) continue;

    Правильный код:

    if (i == bestOffs)
    {
      continue;
    }

    Подобные диагностики невозможно применять к уже существующим проектам, написанным для работы под управлением операционной системы Winodws, Linux или macOS. Например, одно только описанное правило про фигурные скобки даёт 1947 срабатываний диагностики V2507 (MISRA C 15.6, MISRA C++ 6-4-1) для проекта WinMerge. А ведь WinMerge — это маленький проект! Всего около 250 000 строк кода на языке C и C++.

    До 2018 года анализатор PVS-Studio был ориентирован на проверку десктопных приложений, работающих под управлением Windows, Linux и macOS. Соответственно, поддержка MISRA имела мало практического смысла. Никто не будет внедрять в большой существующий десктопный проект этот стандарт.

    Всё изменилось, когда в 2018 году мы начали поддержку встраиваемых систем. В этом году в анализаторе были поддержаны:

    • Windows. IAR Embedded Workbench, C/C++ Compiler for ARM C, C++
    • Windows/Linux. Keil µVision, DS-MDK, ARM Compiler 5/6 C, C++
    • Windows/Linux. Texas Instruments Code Composer Studio, ARM Code Generation Tools C, C++
    • Windows/Linux/macOS. GNU Arm Embedded Toolchain, Arm Embedded GCC compiler, C, C++

    В отличие от десктопных проектов, многие embedded-разработчики уже пишут проекты с учетом MISRA рекомендаций, и их поддержка в нашем анализаторе будет разработчикам однозначно полезна.

    Тем не менее, мы всё равно опасаемся, что кто-то из разработчиков, не разобравшись, может посчитать, что мы «испортили» анализатор внедрением в него «странных диагностик». Поэтому MISRA диагностики по умолчанию выключены. Мы считаем это очень правильным решением. Эти диагностики можно включать, только если вы точно понимаете для чего они нужны и как их использовать.

    Например, для прикладных программистов может быть непонятным, почему вдруг анализатор запрещает им использовать динамическую память. Т.е. почему вдруг нельзя выделять память, используя функцию malloc или оператор new. Но такие ограничения (V2511) хорошо понятны разработчикам встраиваемых устройств. В некоторых устройствах, работающих непрерывно, действительно недопустимо использование программ, для которых вдруг может кончиться память.

    Итак, теперь вы можете установить или обновить PVS-Studio и начать использовать диагностики, реализующие правила из MISRA C и MISRA C++. Набор поддерживаемых правил неполон, но это не должно быть препятствием для начала использования PVS-Studio. На данный момент не существует ни одного статического анализатора, реализующего абсолютно все MISRA правила. В дальнейшем мы планируем расширить набор диагностических правил, реализованных в MISRA, и надеемся стать лидирующим инструментом по полноте их поддержки.

    Чтобы включить MISRA диагностики в Visual Studio или в утилите PVS-Studio Standalone, необходимо в настройках сменить значение Disabled на Show All.

    Включить MISRA

    Поскольку Disabled означает, что предупреждения вообще не генерируются и не попадают в отчёт, то понадобится перезапуск анализа. Режим Disabled по умолчанию установлен для того, чтобы сократить размер отчёта. Включение MISRA диагностик может приводить к огромному количеству срабатываний и сильному увеличению файлов с отчётом (*.plog — файлов).

    Для анализа проектов в операционных системах Linux и macOS существует утилита pvs-studio-analyzer. По умолчанию там включены только диагностики общего назначения (General Analysis, GA). Включить дополнительные правила можно с помощью опции "-a":

    -a [MODE], --analysis-mode [MODE]
            MODE defines the type of warnings:
            1 - 64-bit errors;
            2 - reserved;
            4 - General Analysis;
            8 - Micro-optimizations;
            16 - Customers Specific Requests;
            32 - MISRA.
            Modes can be combined by adding the values
            Default: 4

    Для включения предупреждений GA и MISRA необходимо запустить анализ со следующими параметрами:

    pvs-studio-analyzer analyze ... -a 36 ... -o /path/to/report.log ...

    Значение 36 — это побитовое ИЛИ для 4 (GA — диагностики общего назначения) и 32 (MISRA).

    Далее рекомендуется создать несколько отчётов с разными типами предупреждений, например, так:

    plog-converter -a GA:1,2 -t tasklist
      -o /path/to/ga_results.tasks /path/to/project.log
    plog-converter -a MISRA:1,2,3 -t tasklist -m misra
      -o /path/to/misra_results.tasks /path/to/project.log

    Первый отчёт «ga_results.tasks» будет содержать предупреждения общего назначения уровня достоверности High и Medium.

    А во второй отчёт «misra_results.tasks» попадут только предупреждения, относящиеся к MISRA всех уровней. Ключ "-m misra" указывает, что в отчёт, помимо номеров в формате PVS-Studio, будут включены номера диагностик согласно классификации MISRA.

    Все режимы запуска анализатора в Linux и macOS, а также форматы отчётов, описаны в документации.

    P.S. Мы хотим оценить, насколько мы угадали, выбрав MISRA в качестве одного из направлений развития PVS-Studio. Если Вас заинтересовала эта тема, просьба написать нам. Даже если вы пока не планируете использовать PVS-Studio, всё равно просим написать. Мы хотим задать вам несколько уточняющих вопросов.

    Дополнительные ссылки:

    1. Скачать PVS-Studio
    2. Как запустить PVS-Studio в Linux и macOS
    3. Статический анализатор кода PVS-Studio 6.22 адаптирован для ARM-компиляторов (Keil, IAR)
    4. В PVS-Studio появилась поддержка GNU Arm Embedded Toolchain



    Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. PVS-Studio: Support of MISRA C and MISRA C++ Coding Standards.
    PVS-Studio
    785,00
    Static Code Analysis for C, C++, C# and Java
    Поделиться публикацией

    Похожие публикации

    Комментарии 38

      +4
      Годнота.

      В MISRA 2012 есть 3 уровня правил (обязательные, требуемые и рекомендательные). Есть ли у вас возможность включать отдельные уровни?
        +5
        Наш маппинг соответствует их, то есть:
        • PVS-Studio Level 1 — MISRA обязательные
        • PVS-Studio Level 2 — MISRA требуемые
        • PVS-Studio Level 3 — MISRA рекомендательные

        Соответственно, работа с уровнями предупреждений PVS-Studio аналогична работе с уровнями предупреждений для MISRA.
          0
          Отключить MISRA в настройках для PVS надеюсь возможно?
            0
            Можно. Более того, по умолчанию они как раз выключены.
              0
              Это меня лично радует.
        0
        Интересный инструмент, сейчас используем Tasking для проверки правил Мисры.
        Там не всё гладко, чаще всего проблемы возникают с правилом про Side Effect при сравнении условий (13.5)
          –4
          В MISRA нет правил относящихся к стилю. Все правила нацелены на уменьшение количества багов. В приведенном вами примере с if-ом, фигурные скобки нужны вовсе не для красоты, а чтобы защитить от некоторых часто встречающихся ошибок. К примеру, без фигурных скобок, вызов макроса содержащего несколько операторов, сразу после if-а, приведет к ошибке. Такой вызов может быть очень похож на вызов функции и ошибку могут долго не замечать. В MISRA, кстати, есть пояснения почти ко всем правилам. Странно, что вы их не читали. Честно говоря, эта ваша статья очень разочаровывает. Разработчик статического анализатора обязан иметь хотя-бы элементарное понимание стандартов кодирования. В общем-то они все про баги, а не про стиль.
            +3
            Прозвучало как троллинг, но отвечу. Забавно видеть комментарий «странно, что вы их не читали» после того как стандарты куплены, изучены, реализованы диагностики и по каждой новой диагностике анализатора написана документация на русском и английском языке.

            Теперь к сути. Любой стандарт кодирования призван снизить количество ошибок. В том числе для этого предназначены и правила оформления кода. Я и сам часто пишу о том, как тот или иной вариант оформления кода может снизить количество ошибок. Пример: табличное форматирование (подробнее здесь, см. главу 13). Однако MISRA, как и многие другие стандарты, это именно больше про стиль, а не про баги.

            Вот, например, диагностика V557 обнаруживает выход за границы массива и выявляет конкретные ошибки. В то время как MISRA C++ диагностика V2517 говорит, что вместо суффикса 'u' надо писать 'U'. Да, это помогает избежать ошибок. С этим никто и не спорит. Однако, подобные правила являются ничем иным как способом писать более простой и понятный код, т.е. стандартом оформления кода.

            Так что с «в MISRA нет правил относящихся к стилю» я не согласен. Ещё раз почеркну, что не считаю стилистические правила чем-то плохим. Просто всему своё место.
              +1
              Попробую объяснить ещё раз. MISRA определяет как писать код, который изначально содержит меньше багов. А статический анализатор пытается найти баги в уже написаном коде. Это 2 отдельных слоя защиты от багов. Стиль, оформление кода — это ещё одна, 3-я, отдельная сущность. Где ставить пробелы или как делать отступы. Причём, правила стиля не влияют (!) на количество багов сколько-нибудь заметным образом. Влияет соблюдение единого стиля всеми программистами. В MISRA прямо написано, что они не дают рекомендации относящиеся исключительно к стилю. Т.е. вы спорите с стандартом, а не со мной.
                0
                Я услышал и понял Вас. Согласен, 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 и какую пользу несёт этот стандарт. Однако, этот стандарт надо использовать только при понимании. Иначе, он скорее замедлит и усложнит разработку, не принеся хоть какого-то значимого прироста надёжности и качества.
              0

              Если меня не подводит память, то в PVS-Studio есть отдельная диагностика, которая должна сработать на такой макрос. В таких условиях отсутствие фигурных скобок — и правда лишь вопрос стиля.

                0
                К примеру, без фигурных скобок, вызов макроса содержащего несколько операторов, сразу после if-а, приведет к ошибке.
                Да, такие ошибки ловятся с помощью V640. С её помощью мы не раз находили интересные ошибки в макросах.
                Например:
                В GCC :)

                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

              0
              Неожиданно узнал что PVS умеет в Embedded…
              А совсем жёсткий Embedded — microchip xc семейство C-подобных компиляторов планируется?
              На TI Code Composer Studio проектах обязательно поробую, когда будет больше свободного времени.
                0
                А совсем жёсткий Embedded — microchip xc семейство C-подобных компиляторов планируется?
                Скорее всего, нет. Но если выстроится очередь из нескольких потенциальных клиентов, то это другое дело :).
                  0
                  Очень хотелось бы чтобы вы добавили поддержку CCES от Analog Device. По идее там не сложно ибо это Eclipse, но «вручную» это делать без «встроенной» поддержки со стороны анализатора я, например, точно не буду.

                  Всё что у меня разрабатывается в Visual Studio и лишь портировано в Embedded там всё покрыто и тестами и отпрофилировано алгоритмически и PVS по своим проектам пройдено. Но вот в самих железках тьма ужасного и плохо работающего кода в SDK, драйверах и много где ещё и хоть и приходится его «патчить» чтобы работало не так уныло и не глючило, но качество всё равно оставляет желать лучшего.
                    0
                    > Очень хотелось бы чтобы вы добавили поддержку CCES от Analog Device.

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

                    Кстати тут видимо два вопроса в одном: поддержка компилятора и поддержка IDE? Может оказаться, что компилятор мы уже и так поддерживаем. А для специализированной IDE плагин делать не в плане, так как слишком мало пользователей.
                      +1
                      У меня тоже кругозор не сильно широкий в этой области ибо я не разрабатываю напрямую под Embedded, но иногда приходится «погружаться», а там лютый биоразложимый код не покрытый тестами и дико забагованный уже на уровне идущего в комплекте SDK. Собственно под этой средой я только прошивки собираю, отлаживать в железе что либо там всё равно невозможно ибо каждый шаг в отладчике это ~10 секунд и код не лету править невозможно, хотя в железке ARM ядро не очень древнее.

                      Нужна поддержка, разумеется, только компилятора, поддерживать IDE смысла не имеет никакого ибо это какой то испорченный нестандартный Eclipse. По всей видимости Analog Device это компания «железячников» которая до сих пор не поняла что их куски кремния без ПО и хорошего SDK никому не нужны.

                      P.S. компания на которую сейчас работаю использует «это» лишь потому что продукт поставляется российским военным, а в списках железа которое можно использовать «это» фактически лучшее что есть, ну а внести туда что то реально хорошее маленькой компании невозможно ибо адовая бюрократия и многомиллионные откаты на это требуются.

                      P.P.S. прошу прощения за крик души :'(
                0
                Скачал демо-версию, проверил в Keil, возник вопрос.
                У меня в проекте используется автомат состояний.
                Переменной присваивается какое-то значение, в зависимости от ее значения выполняются те или иные действия.
                При проверке в 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;}   // Неверное значение
                


                Так и должно быть?

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

                    Пример использования автомата состояния
                    // Файл 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)
                      {
                        // Вывод сообщения о ситуации
                      }
                    }
                    

                      0
                      К сожалению, для статических анализаторов, подобный код очень сложен. В том числе и для PVS-Studio. Отслеживать значение глобальных переменных, это неблагодарное дело и делается только в простых случаях :).

                      P.S. Если кому-то интересно чуть подробнее узнать, как работает вычисление значений в PVS-Studio, то предлагаю познакомиться с докладом "Как работает анализ Data Flow в статическом анализаторе кода".
                        0
                        А если бы это был enum, анализатор определил бы, что в switch пропущен один из вариантов? (ошибка с неверным значением при использовании типа enum отпала бы автоматически)
                          0
                          Возможно, сработает V719. Плюс, если в enum запихивают не пойми что, то может помочь V1016.
                          0
                          Ага, спасибо!
                          Жаль, было бы полезно получать такие предупреждения. Так как подобная ошибка может быть плавающей.
                    0
                    После выбора проверки текущего файла:
                    0
                    Сорри, не знал как убить случайно отправленный комент…
                      0
                      Так вот
                      Скриншот VS2017
                      image

                      Не понимает что пишу на Си?
                      Проект для ESP32
                        0
                        Правильно я понимаю, что Вы просто открыли файл и попытались его проверить?

                        Так не получится. В отличии, например, от Cppcheck, анализатор PVS-Studio работает не на регулярных выражениях и должен обладать полной информацией о том, как файл компилируется. Это необходимо, чтобы найти заголовочные файлы, узнать как раскрываются макросы и т.д. Вам нужно создать полноценный компилируемый проект для Visual Studio. Если это сложно, то просто компилируйте файл любым способом и собирайте информацию о ключах запуска компилятора с помощью утилиту PVS-Studio Standalone (см. раздел "Анализ исходных файлов с помощью отслеживания запуска компиляторов"). Аналогичная утилита есть и для Linux.
                          0
                          Спасибо, почитаю.
                          Но думаю дело в другом.
                          Хоть это и полноценный компилируемый проект, но для микроконтроллера ESP32.
                          И происходит эта embedded разработка через плагин VisualGDB.
                        0
                        Как-то слабовато у вас с покрытием не то, что всех правил, но даже правил уровня required. То, что поддерживается, выглядит как простой способ отметиться в теме, не более того. MISRA используются не для отмашки типа «ну да, что-то проверили», а для того, чтобы показать, что написанный код более безопасен и легче в поддержке, чем код, этим правилам не соответствующий.
                        Стыдно должно быть за такие заявления, как «PVS-Studio: поддержка стандартов кодирования MISRA C и MISRA C++». Не поддерживаете вы этот стандарт. Вообще никак. И использовать ваш тул для работы по этому стандарту нельзя. Потому что выхлоп от него — минимальный. И из-за этого ваш тул больше навредит, чем поможет.
                          +2
                          Из общения на конференциях мы знаем, что информация распространяется очень медленно. В этом году мы посетили множество конференций и для многих из подходивших к стенду стало открытием, что у нас появилась поддержка C# или Linux. К тому моменту, когда хоть кто-то узнает что мы поддерживаем MISRA мы серьезно продвинемся в её поддержке. Но начинать писать надо уже сейчас. :)

                          Мы и не говорим, что полностью поддерживаем MISRA. Впрочем, этот стандарт никто полностью никто не поддерживает, что не мешает писать про поддержку :). Это первая версия анализатора, где мы начали добавлять MISRA диагностики. В следующей версии появятся новые диагностики и т.д. Думаю мы достаточно быстро продвинемся в этом направлении и сделаем хорошее покрытие.
                            0
                            Офф-топ: я так понимаю, вы тут друг-другу плюсики ставите?
                            Обратно к теме: от повторения фразы «мы поддерживаем MISRA» поддержка MISRA не появится. Это этика бизнеса, и она у вас, как правописание у Винни Пуха, хромает. Причем на обе ноги. В статье вы говорите о поддержке, как о случившемся факте. Это вранье. Примите это, и не повторяйте таких ошибок в будущем.
                            +2
                            За время развития PVS-Studio хорошо себя зарекомендовала следующая практика. Реализуется какая-то фича. Потом мы находим клиентов, которым нужны те или иные новые компоненты анализатора (диагностики, инструментальные средства, возможности по интеграции). И уже доделываем непосредственно под них. Это позволяет клиентам быстро получать то, что нужно им. В противном случае, выбирая для реализации фичи/диагностики случайным образом, мы будем идти до клиента очень долго.

                            Поэтому если у вас есть интерес к этой теме – давайте вместе сделаем анализатор такой как нужно именно вам. Т.е. напишите список диагностик MISRA которые вы применяете или планируете применять в своей работе. Мы их реализуем и порадуем вас :). А потом уже займёмся прочими диагностиками.
                              0
                              Евгений, если говорить о поддержке стандарта, то как минимум ВСЕ обязательные требования (именно обязательные!) должны поддерживаться по умолчанию. Остальное — обсуждаемо, согласен.
                              Судя по комментариям выше — у вас есть полный текст этого стандарта. Этот стандарт содержит список диагностик MISRA, которые мы применяем или планируем применять в своей работе. Будет здорово, если ваш инструмент начнет поддерживать требования уровня REQUIRED в полном объеме. Спасибо.
                              –1
                              Основная проблема в том, что они не понимают, зачем MISRA вообще нужна! Более того, в ответе на мои комментарии выше (я пытался объяснить), автор пишет: «Я услышал и понял Вас. Согласен, MISRA это не только стиль и оформление кода.» Хотя я написал, что в MISRA вообще нет правил посвящённых стилю! Выходит, что автор таки не слышит. (И выходит, не желает понять.)

                              Далее он приводит цитату из Википедии с критикой MISRA. Я прочитал работу, из которой она взята. К сожалению, там используется тот-же ошибочный взгляд на MISRA, что и у автора этой статьи. Что к правилам MISRA можно применять тот-же критерий качества, что и к предупреждениям статического анализатра. Т.е. отношение количества истинных багов и ложных срабатываний. (В той работе взят код, написанный без соблюдения MISRA и показаны «ужасные» 7000 нарушений MISRA при наличии всего пары десятков реальных багов.)

                              Уважаемый Andrey2008! Правила MISRA придуманы для соблюдения их людьми. Такие правила придумать намного сложнее, чем алгоритмы статического анализатора. Анализатор, например, имеет ряд алгоритмов находящих утечки памяти, а человеку бесполезно говорить: «всегда освобождай память выделенную в куче». Глупо проверять произвольно взятый код на соблюдение MISRA. Код должен изначально писаться под MISRA!

                              Ещё автор пишет, что «никто полностью не поддерживает MISRA». Естественно! В самом стандарте правила делятся на decideable, которые могут быть проверены статическим анализатором и undecideable, которые не могут или могут, но не всегда. Поэтому не может быть написан такой анализатор, который проверяет все правила. В принципе не может!

                              В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта. Но я как-то полагал, что уж кто-кто, а разработчики статик-аналайзера в этом эксперты. Извините господа, но вы спалились…
                                +3
                                Здравствуйте, спасибо за подробные комментарии.

                                > Основная проблема в том, что они не понимают, зачем MISRA вообще нужна!

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

                                > В общем-то, тяжело в двух словах раскрыть тему стандартов разработки софта.

                                Давайте напишем совместную статью про это? Ваш взляд и наш? Можно в форме интервью. Все пользая будет!
                                  –3
                                  Боюсь, от этого не будет никакой пользы… Как раз одна из моих будущих задач на работе — выбрать статик аналайзер и Мисра-чекер. Причём нам не нужен полный Мисра-чекер прямо сейчас, т.к. внедрены только некоторые из правил Мисры. Т.е. они внедрены для внутреннего употребления. Мы не можем заявлять, что как-то соответсвуем Мисре. Выходило, что ваш функционал именно то, что нужно! Поэтому-то я вдвойне заинтересовался этой статьей. Думал, что узнаю что-нибудь новое. Мои знания в этой области сейчас фрагментарны — что-то знаю глубоко, что-то поверхностно. Но, как я писал, увы, статья меня расстроила. Если-бы было написано, что вы частично имплементировали поддержку Мисры, без всяких теоретических рассуждений, то я-бы подумал ОК, вернусь к вашей программе по-позже, когда вплотную займусь выбором аналайзера. Но именно из за этой статьи моё мнение о PVS-Studio поменялось к худшему. Так-что выходит, что вашим клиентом моя компания не станет. И статью я не потяну написать т.к. не чувствую за собой достаточный багаж знаний. Для статьи надо понимать объективную причину для каждого правила, до чего мне ещё далеко. Кроме того, знания о стандартах более высокого уровня (типа DO-178 и IEC-61508) у меня совсем поверхностные. Такие вот дела… Звыняте :-(

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

                            Самое читаемое