Зачем нужен отчёт MISRA Compliance и как его получить в PVS-Studio?

Если вы не понаслышке знаете о MISRA и хотели бы понимать, соответствует ли ваш проект какому-то из стандартов ассоциации MISRA, то есть решение. Имя ему - MISRA Compliance. С недавних пор PVS-Studio научился генерировать отчёт соответствия по этому стандарту, и хочется поделиться тем, как это делается. Возможно, кому-то это упростит жизнь.

Что такое MISRA Compliance

MISRA Compliance – это стандарт, который позволяет понять, соответствует ли ваш проект стандарту MISRA C\C++ с учетом всех отклонений и рекатегоризаций. MISRA Compliance применим ко всем стандартам ассоциации MISRA, но в данной статье мы рассмотрим его использование на примере стандарта MISRA C 2012.

В руководящих принципах MISRA C 2012 признаётся, что в некоторых ситуациях соблюдение требований неоправданно или даже невозможно. В случаях отклонений от правил всё должно быть задокументировано. Однако после может быть проблематично понять, соответствует ли в итоге программа данному стандарту. Здесь на помощь и приходит стандарт MISRA Compliance.

Правила получения MISRA Compliance

Основное, что нужно сделать, – это понять, соответствует ли ваш проект MISRA C 2012 или нет. Для этого нам необходимо получить GCS (Guideline Compliance Summary). GCS включает запись для каждого руководства и регистрирует уровень соответствия им, как это разрешено его категорией MISRA. Проще говоря, нам нужно отобразить номер правила, его категорию и информацию о соответствии с ним. Вот пример как это должно выглядеть:

Номер правила и его категория по умолчанию берутся из стандарта. Однако MISRA Compliance позволяет изменять (рекатегоризировать) уровень руководящих принципов, хоть это и не обязательно. Делается это каждым конкретным пользователем для конкретного проекта в соответствии с GRP (Guideline Re-categorization Plan). GRP – это такой допустимый набор преобразований из одного уровня в другой. Вот так это выглядит в виде таблицы:

И чтобы было проще, давайте на примере. Допустим у нас есть правило 1.1, у которого уровень равен Required. Согласно таблице, мы можем повысить уровень предупреждения до Mandatory или оставить его неизменным. Это отображено зелеными ячейками. При этом понижение уровня до Advisory или Disapplied не допускается. Это отображено красными ячейками.

На основе получившихся категорий для правил можно указывать соответствия. Возможные варианты соответствий для MISRA-категорий выглядят так:

Эта таблица используется для того, чтобы сказать, соответствует ли ваш проект стандарту MISRA C 2012. А конкретно, если у вас есть хотя бы одно соответствие, которое попадает в красную секцию (таблица выше), то вы не соответствуете стандарту.

Чтобы было проще, давайте опять для наглядности возьмём правило 1.1 со стандартным значением категории, равной Required. Смотрим в таблицу и видим, что допустимые значения соответствия для Required – это Compliance или Deviations (чуть подробнее о смысле этих статусов будет в пункте ниже). То есть, если в ваш проект соответствует правилу 1.1, либо соответствует, но с отклонениями, то все хорошо и можно смотреть следующее правило. Если есть хотя бы одно соответствие с Violations или Disapplied, то проект не соответствует MISRA C 2012. Если все правила имеют только допустимые значения, то поздравляю, ваш проект соответствует стандарту MISRA C 2012. Если у вас есть соответствие, которое попадает в красную секцию (таблица выше), то вы не соответствуете стандарту.

Собственно, это все основные вещи, которые нужно знать для генерации MISRA Compliance отчёта.

Генерация отчета MISRA Compliance в PVS-Studio

Чтобы сгенерировать отчет, нужно воспользоваться утилитой PlogConverter.exe или plog-converter на Windows и Unix соответственно. Данные утилиты также распространяются в составе дистрибутивов. На момент написания статьи PVS-Studio умеет выдавать отчёт соответствия только для стандарта MISRA C 2012.

Для генерации отчёта MISRA Compliance необходимо выполнить анализ. Как это сделать на Windows, можно почитать вот тут, а для Unix - тут. Обратите внимание, что вам следует включить все диагностики, связанные с MISRA. Иначе вы добровольно уменьшаете покрытие MISRA-правил. Как проверить, включены ли все правила, описано в предоставленных ссылках на документацию про анализ.

Затем используем одну из утилит конвертации отчёта. Пример запуска PlogConverter.exe:

"C:\Program Files (x86)\PVS-Studio\PlogConverter.exe" "path_to_report_file" \
-t MisraCompliance -o "path_to_MISRA_report" --grp "path_to_grp.txt"

И пример команды для plog-converter:

plog-converter "path_to_report_file" -t misra_compliance \
-o "path_to_MISRA_report" --grp "path_to_grp.txt"

Сам отчёт представляет собой html-страницу, которая удобно подходит для печати. Вот пример отчёта, когда проект не соответствует MISRA C 2012:

Отчёт, когда проект соответствует MISRA C 2012:

Итак, пройдемся по столбцам:

• Guideline содержит номера правил и директив стандарта MISRA C;

• Category содержит категорию правила или директивы, указанную в стандарте;

• Recategorication содержит категорию после рекатегоризации в соответствии с GRP;

• Compliance содержит статус соответствия проверяемого кода правилу. Красным цветом выделено то, что мешает соответствию стандарту MISRA C 2012.

В нашем случае GRP представляет собой txt-файл. Пример содержания файла с допустимыми переходами:

Rule 2.1 = Mandatory
Rule 8.13 = Required
Directive 4.3 = Mandatory
Rule 2.6 = Disapplied

Если этот файл содержит понижение категории, то утилита выдаст сообщение об ошибке и не сгенерирует отчёт. Исключением является Advisory-категория, которая может понижаться до Disapplied. Если что, то вот так располагаются категории от наиболее важной к наименее важной:

Статусы соответствия проверяемого кода означают следующее:

• Compliant – в проекте нет отклонений по данному правилу;

• Deviations – отклонения от правила обнаружены и задокументированы. Чтобы утилита поняла про необходимость игнорирования конкретного предупреждения, его следует разметить как ложное (Mark as False Alarm). В скобочках указывается число подтвержденных отклонений;

• Violations – существует хотя бы одно отклонение от правила, которое не было задокументировано. В скобочках указывается число таких отклонений. Если кроме Violations для правила есть и Deviations-предупреждения, то будут отображены оба статуса;

• Disapplied – категория выключена и никак не будет учитываться. Применимо только к Advisory-категориям;

• Not Supported – данное правило не поддерживается анализатором. На момент написания статьи PVS-Studio уже покрыло 60% стандарта MISRA C 2012. Но мы на этом не останавливаемся и планируем к концу года повысить этот показатель до 85%.

Ну и самое главное – это заключение о соответствии или несоответствии проекта стандарту MISRA C 2012. Код соответствует стандарту, если:

• Все Mandatory-правила имеют статус Compliant;

• Все Required-правила имеют статус Compliant и\или Deviations;

• Advisory-правила могут иметь любой статус;

• Disapplied-правила игнорируются.

Заключение

Не стесняйтесь пробовать новый отчёт. Если возникнут какие-либо трудности, проблемы или пожелания, то обязательно напишите нам в поддержку.

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

1. Что такое MISRA и как её готовить.

2. Классификация предупреждений PVS-Studio согласно стандартам: MISRA C, MISRA C++.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Nikolay Mironov. Why do you need the MISRA Compliance report and how to generate one in PVS-Studio?.