Зависимость средства проверки правил кодирования MISRA-C от компилятора

#c #misra

Вопрос:

Я начал использовать инструмент, позволяющий проверить соответствие требованиям MISRA-C 2012. Инструмент-Helix QAC. Во время настройки он запрашивает выбор одного компилятора. Насколько я понимаю, MISRA-C (и правила кодирования в целом) не связаны с набором инструментов компилятора, поскольку одной из их целей является переносимость. Кроме того, одно из правил MISRAC-не использовать языковые расширения (очевидно, что это правило может быть отключено или из него могут быть исключения). Документация или поддержка Helix довольно расплывчаты по этому поводу (все еще пытаясь получить от них дополнительную информацию) и просто упоминают о необходимости знать длину целочисленного типа или путь стандартных включений. Но анализ правил должен быть независимым от int размера, а интерфейс standard includes является стандартным, поэтому фактические файлы не должны быть нужны.

Каковы зависимости между средством проверки правил MISRA-C и компилятором ?

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

1. Я думаю, что не очень понятно, о чем именно вы спрашиваете.

2. «Что ты думаешь?» — это слишком широко. В чем проблема?

3. Какие зависимости существуют между средством проверки MISRA и компилятором-это довольно конкретный вопрос, если вы просто отбросите «Что вы думаете?» в конце.

4. Учитывая, что ваш вопрос «Почему этому инструменту проверки MISRA-C необходимо знать, какой компилятор я использую?», мой вопрос к вам: «Почему вас волнует, что инструмент хочет знать, какой компилятор вы используете?». Если только вы не задаете этот вопрос просто из любопытства (и это законно), но, боюсь, на ваш вопрос может полностью ответить только разработчик инструмента.

5. @GuillaumePetitjean MISRA-C сам по себе (5.3.2) также требует, чтобы вы задокументировали, как вы настраиваете статический анализатор, какие вещи вы настроили, чтобы он игнорировался, и почему и т. Д. По иронии судьбы, теперь я вижу, что этот текст в строках руководства MISRA представляет собой тот же пример логического типа, что и в ответе ниже 🙂

Ответ №1:

Некоторые из руководящих принципов зависят от знания того, что делает реализация — это особенно относится к определенным аспектам реализации, включая (но не ограничиваясь целочисленными размерами, максимальными/минимальными значениями, методом реализации логического и т. Д.)

В MISRA C даже есть раздел 4.2 «Понимание компилятора«, который в сочетании с разделом 4.3 «Понимание инструмента статического анализа» решает эти проблемы.

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

1. Действительно, раздел 4.3 частично отвечает на мой вопрос, поскольку в нем говорится : «Документация по каждому инструменту статического анализа, используемому в проекте, должна быть рассмотрена, чтобы понять, как настроить анализатор в соответствии с определяемым компилятором поведением, определяемым реализацией, например, размерами целочисленных типов (…)». Я

Ответ №2:

Есть одна вещь, которую должен знать каждый контролер MISRA-C, и это то, какой тип вы используете в качестве bool . Это необходимо, так как MISRA-C:2012 все еще поддерживает C90, который не имел стандартной поддержки логического типа. (Приложения C99 должны использовать _Bool / bool , точка.) Ему также необходимо знать, каким константам соответствуют значения false и true в случае stdbool.h false , true если они недоступны. Это может быть причиной, по которой он спрашивает, какой компилятор используется. Подробную информацию см. в Приложении D — Основные типы.

Размеры типов int etc не имеют значения для проверки MISRA. Хотя это могло бы быть неплохо, если бы вы знали о нестандартных расширениях. Нам не разрешается использовать нестандартные расширения или поведение, определяемое реализацией, без их документирования. Обычные подозреваемые-встроенный ассемблер, прерывания, выделение памяти в определенных местах и так далее. Но как только мы задокументируем их в нашем отклонении к Dir 1.1/Правилу 1.1, мы, возможно, захотим отключить предупреждения об использовании этих конкретных, разрешенных отклонений. Если средство проверки MISRA совершенно не знает об определенной функции, то как вы можете отключить предупреждение, вызванное ею?

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

1. Я не знаю и не использовал инструмент Helix QAC, но я знаю, что многие инструменты предоставляют дополнительные функции/проверки (помимо MISRA-C), так что это может быть причиной, по которой инструменту int , например, нужна информация о размере.

2. @LucaPolito Да, это тоже правда, они обычно проверяют много вещей за пределами МИСРА-С (если они хоть сколько-нибудь хороши).

3. @Lundin так вы имеете в виду, что компилятор будет определять bool себя даже при настройке в C90 ?

4. @GuillaumePetitjean Да, в компиляторах embedded systems C90 обычно было какое-то нестандартное расширение, где вы могли найти какой-то самодельный логический тип в каком-то заголовочном файле. Хотя, оглядываясь назад, комментарий Луки выше, вероятно, является основной причиной, по которой инструмент хочет знать компилятор, так что это вовсе не обязательно для целей MISRA-C.