Документация

Текстовое All code shall conform to ISO 9899:1990 Programming languages C, amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996 предшествует каждому из следующих сообщений:

Никаких предупреждений, если код инкапсулирован в следующем:

Комментарии C++ обрабатываются как комментарии, но приводят к нарушению этого правила MISRA

Примечание.Это правило нельзя аннотировать в исходном коде.

Это нарушение правил также возникает, когда последовательность символов/* внутри комментария C++.

Примечание.Это правило нельзя аннотировать в исходном коде.

Чекер использует внутреннюю эвристику, чтобы обнаружить закомментированный код. Для образца такие символы, как #, ;, { или } указать комментарии, которые потенциально могут содержать код. Эти комментарии затем оцениваются по другим метрикам, чтобы определить вероятность маскировки кода как комментария. Для образца несколько последовательных слов без символа между ними уменьшают эту вероятность.

Шашка не помечает следующие комментарии, даже если они содержат код:

Чекер считает, что эти комментарии предназначены для целей документации или были внесены преднамеренно с некоторой дальновидностью.

Все виды применения директивы # pragma должны быть задокументированы и разъяснены.

Проверяются все идентификаторы (глобальные, статические и локальные).

Для более легкого просмотра, проверка правил показывает все идентификаторы, которые имеют те же первые 31 символ, что и одно нарушение правил. В истории событий нарушения правил можно увидеть все образцы конфликтующих имен идентификаторов.

Эта проверка деактивируется в Polyspace по умолчанию при анализе You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

5.2

Идентификаторы во внутренних возможностях не должны использовать то же имя, что и идентификаторы во внешних возможностях, и поэтому скрывать этот идентификатор.

Принимает, что правило 8.1 не нарушается.

5.3

Имя typedef должно быть уникальным идентификатором

{typedef name} «»% s «» не следует повторно использовать. (уже используется как {typedef name} в% s:% d)

Предупреждение, когда имя typedef повторно используется как другое имя идентификатора.

5.4

Имя тега должно быть уникальным идентификатором

{имя тега} «»% s «» не следует повторно использовать. (уже используется как {имя тега} в% s:% d)

Предупреждение, когда имя тега повторно используется как другое имя идентификатора

Эта проверка деактивируется в Polyspace по умолчанию при анализе You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

5.5

Не следует повторно использовать идентификатор объекта или функции со статической длительностью хранения.

{статический идентификатор/имя параметра} «% s» не следует повторно использовать. (уже используется как {статический идентификатор/имя параметра} со статической продолжительностью хранения в% s:% d)

Предупреждение, когда статическое имя повторно используется как другое имя идентификатора

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

5.6

Ни один идентификатор в одном пространстве имен не должен иметь такой же орфографии, как идентификатор в другом пространстве имен, за исключением структуры и имен представителей объединения.

{представитель} «»% s «» не следует повторно использовать. (уже используется как {представитель} в% s:% d)

Предупреждение при idf в пространстве имен повторно используется в другом пространстве имен

Эта проверка деактивируется в Polyspace по умолчанию при анализе You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

5.7

Имя идентификатора не должно использоваться повторно.

{идентификатор} «»% s «» не должен использоваться повторно. (уже используется как {identifier} в% s:% d)

О нарушениях не сообщается, когда:

6.1

Обычный тип char должен использоваться только для хранения и использования значений символов

Только допустимые операторы на простых графиках: '=', '= =' или '! =', явные приведения к интегральным типам и '?' (для 2-го и 3-го операндов)

Предупреждение, когда обычный char используется с оператором, отличным от =, = =,! =, явное приведение к интегральным типам или как второй или третий операнд? оператор.

6.2

6.3

вместо основных типов следует использовать шрифты, указывающие на размер и сигнальность

вместо основных типов следует использовать шрифты, указывающие на размер и сигнальность.

В определении typedef предупреждение не приводится.

6.4

Битовые поля должны быть определены только как беззнаковые int или signed int.

Битовые поля должны быть определены только как беззнаковые int или signed int.

6.5

Битовые поля типа int должны иметь длину не менее 2 бит.

Битовые поля типа int должны иметь длину не менее 2 бит.

Нет предупреждений на анонимных входных битовых полях ширины 0 - расширен на все подписанные битовые поля размера < = 1 (если нарушено правило 6.4).

Функции должны иметь объявления прототипа, и прототип должен быть виден как при определении функции, так и при вызове.

Прототип, видимый по вызову, должен быть завершен.

Всякий раз, когда объект или функция объявлены или определены, его тип должен быть четко указан

Всякий раз, когда объект или функция объявлены или определены, его тип четко указывается.

Если объекты или функции объявлены более одного раза, их типы должны быть совместимыми.

Нарушения этого правила могут быть сгенерированы во время фазы ссылки.

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

Эта проверка деактивируется в Polyspace по умолчанию при анализе You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

В заголовочном файле не должно быть определений объектов или функций

Предварительные определения рассматриваются как определения. Для объектов со возможностями файла предварительными определениями являются объявления, которые:

Функции должны всегда объявляться в возможностях файла.

Функция 'XX' должна быть объявлена в области файлов.

Это правило сопоставлено с идентификатором ISO/IEC TS 17961 addrescape.

Ограничены явными объявлениями extern (предварительные определения игнорируются).

Polyspace считает, что переменные или функции объявлены extern в файле без заголовка нарушают это правило.

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

Эта проверка деактивируется в Polyspace по умолчанию при анализе You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

Идентификатор с внешним редактированием должен иметь только одно внешнее определение.

Проверка помечает несколько определений только в том случае, если определения происходят в разных файлах.

На предопределенных символах предупреждения не появляются.

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

Эта проверка деактивируется в Polyspace по умолчанию при анализе You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

Все объявления и определения объектов или функций в объеме файла должны иметь внутреннее редактирование, если не требуется внешнее редактирование

Функция/Переменная XX должна иметь внутреннее редактирование.

Принимает, что 8.1 не нарушается. Нет предупреждения, если использует 0.

Если ваш код не содержит main и вы используете такие опции, как Variables to initialize (-main-generator-writes-variables) со значением custom чтобы явным образом задать набор переменных для инициализации, средство проверки не помечает эти переменные. Проверка предполагает, что в реальном приложении файл, содержащий main необходимо инициализировать переменные в дополнение к любому файлу, который в данный момент использует их. Поэтому переменные должны использоваться в нескольких модулях преобразования.

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

Эта проверка деактивируется в Polyspace по умолчанию при анализе You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

Спецификатор статического класса памяти должен использоваться в определениях и декларациях объектов и функций, имеющих внутренние редактирования

статический спецификатор класса памяти должен использоваться для символа внутреннего редактирования XX.

Когда массив объявлен с внешним редактированием, его размер должен быть указан явно или определен неявно путем инициализации

Размер массива 'XX' должен быть явно указан.

Перед использованием всем автоматическим переменным должно быть присвоено значение.

Проверяется во время анализа кода.

Нарушения, отображаемые как Неинициализированные результаты переменной.

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам. В Code Prover также можно увидеть различие в результатах, основанную на вашем выборе для опции Verification level (-to). Смотрите раздел «Проверка на нарушения стандартов кодирования».

Скобки должны использоваться для указания и согласования структуры в ненулевой инициализации массивов и структур.

Скобки должны использоваться для указания и соответствия структуры в ненулевой инициализации массивов и структур.

В списке перечислителей конструкция = не должна использоваться для явной инициализации представителей, отличных от первой, если только все элементы не инициализированы явным образом.

В списке перечислителей конструкция = не должна использоваться для явной инициализации представителей, отличных от первой, если только все элементы не инициализированы явным образом.

Значение выражения целого типа не должно неявно преобразовываться в другой базовый тип, если:

Основа типов ANSI C (signed char, short, int, long) определяет, что T2 шире T1, если T2 находится справа от T1 или T2 = T1. Такая же интерпретация применяется и к беззнаковой версии базовых типов.

Выражение типа bool или enum имеет int как базовый тип.

Обычный char мог иметь подписанный или неподписанный базовый тип (в зависимости от целевого строения Polyspace или настройки опций).

Базовый тип простого выражения struct.bitfield является базовым типом, используемым в определении битового поля, ширина битового поля не лексемы в расчет и принимает, что для битового поля используются только подписанные | беззнаковые int (Правило 6.4).

О нарушениях не сообщается, когда:

Никаких нарушений не сообщалось, когда все следующие значения true:

Об операциях с указателями нарушений не сообщалось.

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

Значение выражения плавающего типа не должно неявно преобразовываться в другой тип, если

Основа типов ANSI C (с плавающей точкой, double) определяет, что T2 шире T1, если T2 находится справа от T1 или T2 = T1.

О нарушениях не сообщается, когда:

Значение комплексного выражения целого типа может быть приведено только к типу, который уже и имеет ту же сигнальность, что и базовый тип выражения

Комплексное выражение базового типа XX может быть приведено только к более узкому целому типу с той же сигнальностью, однако целевой тип является XX.

Значение комплексного выражения типа с плавающей точкой может быть приведено только к более узкому плавающему типу

Комплексное выражение XX типа может быть приведено только к более узкому плавающему типу, однако конечным типом является XX.

Основа типов ANSI C (с плавающей точкой, double) определяет, что T1 уже T2, если T2 находится справа от T1 или T2 = T1. 

Если побитовые ~ оператора и < < применяются к операнду базового типа без знака char или без знака short, результат должен быть немедленно приведен к базовому типу операнда

Bitwize [<<|~] применяется к операнду базового типа [без знака char 'unsigned short], результат должен быть немедленно приведен к базовому типу.

Суффикс «U» применяется ко всем константам неподписанных типов

Нет явного суффикса 'U для констант неподписанного типа.

 Предупреждение, когда тип, определенный из значения и основы (восьмеричный, десятичный или шестнадцатеричный), не подписан и суффикса нет u или U.

Для примера, когда размер int и long int типы данных - 32 бита, проверка правил кодирования сообщит о нарушении правила 10.6 для следующей линии:

int a = 2147483648;

Существует различие между десятичной и шестнадцатеричной константами при int и long int не совпадают по размеру.

Преобразование не должно выполняться между указателем на функцию и любым типом, отличным от интегрального типа

Преобразование не должно выполняться между указателем на функцию и любым типом, отличным от интегрального типа.

Приведения и неявные преобразования с использованием указателя на функцию.

Смещения или неявные преобразования из NULL или (void*)0 не предупреждать.

Преобразование не должно выполняться между указателем на объект и любым типом, отличным от интегрального типа, другим указателем на тип объекта или указателем на удаление

Преобразование не должно выполняться между указателем на объект и любым типом, отличным от интегрального типа, другим указателем на тип объекта или указателем на удаление.

Существует также предупреждение о потере квалификатора

Это правило сопоставлено с идентификатором ISO/IEC TS 17961 alignconv.

Приведение не должно выполняться между типом указателя и интегральным типом

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

Исключение при нулевой константе. Расширенный ко всем преобразованиям

Это правило сопоставлено с идентификатором ISO/IEC TS 17961 alignconv.

Приведение не должно выполняться между указателем на тип объекта и другим указателем на тип объекта.

Приведение не должно выполняться между указателем на тип объекта и другим указателем на тип объекта.

Не должно выполняться приведение, которое удаляет любую несовпадающую или изменчивую проверку из типа, адресованного указателем.

Не должно выполняться приведение, которое удаляет любую несовпадающую или изменчивую проверку из типа, адресованного указателем.

Расширенный ко всем преобразованиям

Ограниченная зависимость должна быть помещена в выражения в правилах приоритета операторов C

Ограниченная зависимость должна быть помещена в выражения в правилах приоритета операторов C

Проверка правила 12.2 предполагает, что в выражениях, которые дают логические значения (правило 13.1), назначение не выполняется.

Выражение является простым выражением символов. i = i++; является нарушением, но tab[2] = tab[2]++; не является нарушением.

The sizeof оператор не должен использоваться в выражениях, содержащих побочные эффекты.

The sizeof оператор не должен использоваться в выражениях, содержащих побочные эффекты.

Нет предупреждений о летучих доступах

Операнд правой руки логического & & или || оператора не должен содержать побочных эффектов.

Операнд правой руки логического & & или || оператора не должен содержать побочных эффектов.

Нет предупреждений о летучих доступах

Операнды логического & & или || должны быть первичными.

Во время предварительной обработки нарушения этого правила обнаруживаются в выражениях в директивах # if.

Разрешено исключение для ассоциативно (a & & b & & c), (a || b || c).

Операнды логических операторов (& &, || и!) должны быть эффективно логическими. Выражение, которое эффективно является логическим, не должно использоваться в качестве операторов для других операторов (& &, || или!).

Операнд логического оператора должен быть логическим типом данных. Несмотря на то, что стандарт C явным образом не определяет тип логических данных, стандарт неявно предполагает использование типа логических данных.

Некоторые операторы могут возвращать логические выражения, например (var == 0).

Примите во внимание следующий код:

unsigned char flag;
if (!flag)

Проверка правил сообщает о нарушении правила 12.6:

Operand of '!' logical
operator should be 
effectively Boolean.

Чтобы соответствовать правилу 12.6, код должен быть переписан либо как

if (!( flag != 0))

if (flag == 0)

Использование опции -boolean-types может увеличить или уменьшить количество сгенерированных предупреждений.

Битовые операторы не должны применяться к операторам, основной тип которых подписан

Базовый тип для целого числа подписан, когда:

Операнд правой руки оператора сдвига должен находиться между нулем и на единицу меньше ширины в битах базового типа операнда левой руки.

Числа, которыми манипулируют в директивах предварительной обработки, имеют ширину 64 бита, так что допустимая область значений сдвигов находится между 0 и 63

Проверка также распространяется на битовые поля с шириной поля или шириной базового типа, когда она находится в пределах комплексного выражения

Оператор унарного минуса не применяется к выражению, базовый тип которого не подписан.

Базовый тип для целого числа подписан, когда:

Оператор запятыми не должен использоваться.

Оператор запятыми не должен использоваться.

Оценка постоянных беззнаковых целочисленных выражений не должна приводить к переносу.

Предупреждение, когда:

Операторы шага (+ +) и декремента (--) не должны смешиваться с другими операторами в выражении

Операторы шага (+ +) и декремента (--) не должны смешиваться с другими операторами в выражении

Предупреждение, когда операторы++ или -- не используются в одиночку.

Операторы назначения не должны использоваться в выражениях, которые дают логические значения.

Операторы назначения не должны использоваться в выражениях, которые дают логические значения.

Тесты значения против нуля должны быть сделаны явными, если только операнд не является фактически логическим

Тесты значения против нуля должны быть сделаны явными, если только операнд не является фактически логическим

На целочисленных константах предупреждение не выдается. Пример: if (2)

Использование опции -boolean-types может увеличить или уменьшить количество сгенерированных предупреждений.

Логические операции, результаты которых инвариантны, не допускаются

Во время компиляции проверяйте сравнения по крайней мере с одним постоянным операндом.

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

В Code Prover также можно увидеть различие в результатах, основанную на вашем выборе для опции Verification level (-to). Смотрите проверку на нарушения стандартов кодирования..

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

enum ec {RED, BLUE, GREEN} 
    col;
for(col=RED; col<=GREEN; 
    col++)
{}

enum ec {RED, BLUE, GREEN} 
   col;
for(col=RED; (int)col<=GREEN;
    col++ )
{}

Не должно быть недостижимого кода.

Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

Все операторы, отличные от null, должны иметь или по крайней мере один побочный эффект, однако выполненный, или привести к изменению потока управления

Все операторы без нуля должны:

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

Мы предполагаем, что ';' является пустым оператором, когда он является первым символом на линию (исключая комментарии). Правило нарушается, когда:

Не допускается использование оператора goto.

Не допускается использование оператора goto.

Продолжение оператора не должно использоваться.

Продолжение оператора не должно использоваться.

Для любого оператора итерации должен быть не более одного оператора пропуска, используемого для завершения цикла

Для любого оператора итерации должен быть не более одного оператора пропуска, используемого для завершения цикла

Функция должна иметь одну точку выхода в конце функции

Функция должна иметь одну точку выхода в конце функции

Оператор, образующий тело коммутатора, в то время как, делать в то время или для оператора, должен быть составным оператором

За конструкцией if (выражение) следует составной оператор. За другим ключевым словом следует либо составной оператор, либо другой оператор if

Все, если еще конструкции должны содержать предложение final else.

Все, если еще конструкции должны содержать предложение final else.

Должен использоваться синтаксис коммутатора MISRA C.

синтаксические нормативные ограничения операторов switch.

Предупреждение об объявлениях или любых операторах перед первым случаем переключения.

Предупреждение о метке или операторах перехода в теле случаев переключения.

В следующем примере правило отображается в файле журнала в линии 3:

1 ...
2 switch(index) {
3  var = var + 1; 
// RULE 15.0 
// violated
4case 1: ...

Код между оператором switch и первым случаем проверяется Polyspace как мертвый код. Оно соответствует стандартному поведению ANSI.

Это правило не рассматривается как обязательное правило в правилах C:2004 MISRA для сгенерированного кода. В сгенерированном коде, если вы находите нарушение правила 15.0, которое не нарушает одновременно более позднее правило в этой группе, обосновывайте нарушение соответствующими комментариями.

Метка switch должна использоваться только в том случае, если наиболее близко заключенный составной оператор является телом оператора switch

Метка switch должна использоваться только в том случае, если наиболее близко заключенный составной оператор является телом оператора switch

Оператор безоговорочного пропуска прекращает действие каждого пункта о непустом переключателе

Оператор безоговорочного пропуска прекращает действие каждого пункта о непустом переключателе

Предупреждение для каждого положения о несоответствующем делу.

Конечным пунктом оператора switch является пункт по умолчанию

Конечным пунктом оператора switch является пункт по умолчанию

Выражение switch не должно представлять значение, которое эффективно является логическим

Выражение switch не должно представлять значение, которое эффективно является логическим

Использование опции -boolean-types может увеличить количество сгенерированных предупреждений.

Каждый оператор switch должен иметь по крайней мере один пункт случая

Каждый оператор switch должен иметь по крайней мере один пункт случая

Функции не должны определяться переменным числом аргументов.

Функция XX не должна быть определена как varargs.

Функции не должны вызывать себя, прямо или косвенно.

Функция% s не должна вызывать сама себя.

Чекер сообщает о каждой функции, которая вызывает себя, прямо или косвенно. Даже если несколько функций участвуют в одном цикле рекурсии, каждая функция сообщается индивидуально.

Общее количество циклов рекурсии можно вычислить с помощью метрики сложности кода Number of Recursions.

Идентификаторы должны быть даны для всех параметров в объявлении прототипа функции.

Идентификаторы должны быть даны для всех параметров в объявлении прототипа функции.

Принимает, что правило 8.6 не нарушено.

Принимает, что правила 8.8, 8.1 и 16.3 не нарушаются.

Все вхождения обнаружены.

Функции без параметров должны быть объявлены с типом параметра void.

Функции без параметров должны быть объявлены с типом параметра void.

Также проверяются определения.

Принимает, что правило 8.1 не нарушается.

Это правило сопоставлено с идентификатором ISO/IEC TS 17961 argcomp.

Параметр указателя в прототипе функции должен быть объявлен как указатель на const если указатель не используется для изменения адресуемого объекта.

Параметр указателя в прототипе функции должен быть объявлен как указатель на const если указатель не используется для изменения адресуемого объекта.

Предупреждение, если не const параметр указателя либо не используется для изменения адресуемого объекта, либо передается на вызов функции, которая объявлена как const параметр указателя.

Все выходные пути из функции с непустым типом возврата должны иметь явный оператор возврата с выражением.

Отсутствующее возвращаемое значение для непустой функции XX.

Предупреждение, когда функция, не являющаяся пустой, не прерывается безусловным возвратом с выражением.

Идентификатор функции должен использоваться только с предыдущим &, или со списком параметров в круглых скобках, который может быть пустым.

Идентификатору функции XX должен предшествовать & или последующий список параметров.

Если функция возвращает информацию об ошибке, эта информация об ошибке должна быть проверена.

Если функция возвращает информацию об ошибке, эта информация об ошибке должна быть проверена.

Шашечные флаги функционируют без void возвращает, если возвращаемое значение не используется или явным образом не приведено к void тип.

Шашка не помечает функции memcpy, memset, memmove, strcpy, strncpy, strcat, strncat потому что эти функции просто возвращают указатель на свои первые аргументы.

Арифметика указателя применяется только к указателям, которые адресованы элементу массива или массива.

Арифметика указателя применяется только к указателям, которые адресованы элементу массива или массива.

>, > =, <, < = не применяется к типам указателей, кроме тех случаев, когда они указывают на один и тот же массив.

>, > =, <, < = не применяется к типам указателей, кроме тех случаев, когда они указывают на один и тот же массив.

Предупреждение о:

Предупреждение при назначении адреса глобальной переменной, возвращении локального адреса переменной или возвращении адреса параметра.

Это правило сопоставлено с идентификатором ISO/IEC TS 17961 accfree.

Все типы конструкций или объединений должны быть завершены в конце модуля перевода.

Все типы конструкций или объединений должны быть завершены в конце модуля перевода.

Предупреждение для всех неполных деклараций структур или объединений.

Объект не должен быть назначен перекрывающемуся объекту.

Объединения не должны использоваться

Объединения не должны использоваться.

Операторам # include в файле должны предшествовать только другие директивы или комментарии предпроцессоров

Сообщение отображается, когда директиве # include предшествуют другие вещи, чем директивы препроцессора, комментарии, пространства или «новые линии».

Нестандартные символы не должны присутствовать в именах заголовочных файлов в директивах # include

После директивы # include следует последовательность < filename > или «filename».

Макрос «» < имя > «» не расширяется на совместимую конструкцию.

Мы предполагаем, что определение макроса не нарушает это правило, когда оно расширяется на:

Макросы не должны быть # defined и # undefd внутри блока.

# undef не должен использоваться.

#undef не должны использоваться.

Функция должна использоваться в выборе функции, подобной макросу.

Функциональный макрос не должен вызываться без всех его аргументов

Аргументы в функциональный макрос не должны содержать лексемы, которые выглядят как директивы предварительной обработки.

Аргумент макроса не должен выглядеть как директива предварительной обработки.

Это правило обнаруживается как нарушенное, когда символ '#' появляется в аргументе макроса (вне строковой или символьной константы)

В определении функционального макроса каждый образец параметра должен быть заключен в круглые скобки, если он не используется в качестве операнда # или # #.

Образец параметра должен быть заключен в круглые скобки.

Если x является параметром макроса, следующие образцы x как операнда операторов # и # # не генерируют предупреждение: #x, ##x, и x##. В противном случае круглые скобки требуются вокруг x.

Программа не генерирует предупреждение, если параметр повторно используется в качестве аргумента функции или подобного функции макроса. Например, рассмотрим параметр x. Программное обеспечение не генерирует предупреждение, если x появляется следующим (x) или (x, или ,x) или ,x,.

Все идентификаторы макросов в директивах препроцессора должны быть определены перед использованием, за исключением директивы предпроцессора # ifdef и # ifndef и оператора defined ().

'< имя >' не определено.

Должно быть не более одного вхождения операторов предпроцессора # или # # в одном определении макроса.

Несколько вхождения операторов предварительной обработки # или # #.

Операторы предпроцессора # и # не должны использоваться

Сообщение об определениях макросов, использующих операторы # или # #

Определенный оператор препроцессора должен использоваться только в одной из двух стандартных форм.

'defined' без идентификатора.

Когда заголовочный файл форматирован как,

#ifndef <control macro>
#define <control macro> 
<contents> #endif

или,

#ifndef <control macro>
#error ...
#else 
#define <control macro> 
<contents> #endif

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

Директивы предварительной обработки должны быть синтаксически значимыми, даже если исключены препроцессором.

директива не является синтаксически значимой.

Все директивы # else, # elif и # endif предпроцессора должны находиться в том же файле, что и директива # if или # ifdef, с которой они связаны.

Зарезервированные идентификаторы, макросы и функции в стандартной библиотеке не должны быть определены, переопределены или неопределены.

Имена стандартных библиотечных макросов, объектов и функций не должны использоваться повторно.

Идентификатор XX не должен использоваться.

В случае, если определен макрос, имя которого соответствует стандартному библиотечному макросу, объекту или функции, правило, которое обнаруживается как нарушенное, является 20.1.

Предварительные определения рассматриваются как определения. Для объектов со возможностями файла предварительными определениями являются объявления, которые:

Проверяется валидность значений, переданных в библиотечные функции.

Проверяется достоверность значений, переданных в библиотечные функции

Предупреждение для аргумента в вызове функции библиотеки, если все следующие значения true:

Функция библиотеки может быть одной из следующих: sqrt, tan, pow, log, log10, fmod, acos, asin, acosh, atanh, или atan2.

Bug Finder и Code Prover проверяют это правило по-разному. Анализ может привести к различным результатам.

Динамическое выделение памяти «куча» не должно использоваться.

В случае, если динамические функции выделения памяти «куча» на самом деле являются макросами, и макрос расширен в коде, это правило обнаруживается как нарушенное. Принимает, что правило 20.2 не нарушено.

Индикатор ошибки errno не должен использоваться

Индикатор ошибки errno не должен использоваться

Принимает, что правило 20.2 не нарушается

Смещение макроса в библиотеке < stddef.h > не должно использоваться.

Принимает, что правило 20.2 не нарушается

Макрос setjmp и функция longjmp не должны использоваться.

В случае, если функция longjmp на самом деле является макросом, и макрос расширен в коде, это правило обнаруживается как нарушенное. Принимает, что правило 20.2 не нарушается

Средства обработки сигналов < signal.h > не должны использоваться.

В случае, если некоторые функции сигнала являются фактически макросами и расширены в коде, это правило обнаруживается как нарушенное. Принимает, что правило 20.2 не нарушается

Библиотека ввода/вывода < stdio.h > не должна использоваться в производственном коде.

В случае, если функции библиотеки ввода/вывода являются фактически макросами и расширены в коде, это правило обнаруживается как нарушенное. Принимает, что правило 20.2 не нарушается

Не должны использоваться библиотечные функции atof, atoi и atoll из библиотеки < stdlib.h >.

В случае, если функции atof, atoi и atoll на самом деле являются макросами и расширяются, это правило обнаруживается как нарушенное. Принимает, что правило 20.2 не нарушается

Не должны использоваться функции library abort, exit, getenv и система из библиотеки < stdlib.h >.

В случае, если прерывание, выход, getenv и системные функции на самом деле являются макросами и расширяются, это правило обнаруживается как нарушенное. Принимает, что правило 20.2 не нарушается

Функции обработки времени библиотеки < time.h > не должны использоваться.

В случае, если функции обработки времени фактически являются макросами и расширены, это правило определяется как нарушенное. Принимает, что правило 20.2 не нарушается

Минимизация отказов в работе должна обеспечиваться при помощи, по крайней мере, одного из:

Сделано Polyspace. Bug Finder и Code Prover по-разному проверяют это правило кодирования. Анализы могут привести к различным результатам.

В Code Prover также можно увидеть различие в результатах, основанную на вашем выборе для опции Verification level (-to). Смотрите проверку на нарушения стандартов кодирования..

Не следует полагаться на неопределенное или неопределенное поведение

Статически не проверяется, если только не учитываются динамические свойства данных

Несколько компиляторов и/или языков должны использоваться только в том случае, если существует общий определенный стандарт интерфейса для объектного кода, которому соответствуют языки/компиляторы/ассемблеры.

Это метод правила процесса.

Компилятор/линкер/идентификаторы (внутренние и внешние) не должны полагаться на значимость более 31 символа. Кроме того, компилятор/линкер должен быть проверен, чтобы убедиться, что для внешних идентификаторов поддерживаются 31 символ значимости и чувствительности к регистру.

Чтобы соблюдать это правило, проверьте документацию компилятора.

Реализации с плавающей точкой должны соответствовать определенному стандарту с плавающей точкой.

Чтобы соблюдать это правило, проверьте документацию компилятора.

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

Чтобы соблюдать это правило, проверьте документацию компилятора. Выявление ошибок основано на неопределенном поведении, в соответствии с выбором, сделанным для конструкций, заданных реализацией.

Набор символов и соответствующая кодировка должны быть задокументированы.

Чтобы соблюдать это правило, проверьте документацию компилятора.

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

Чтобы соблюдать это правило, проверьте документацию компилятора.

Определяемое реализацией поведение и упаковка битовых полей должны быть задокументированы, если на них полагаются.

Чтобы соблюдать это правило, проверьте документацию компилятора.

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

Чтобы соблюдать это правило, проверьте документацию компилятора.

Область памяти не должна повторно использоваться в несвязанных целях.

«назначение» - вопрос функционального проекта.