exponenta event banner

Подмножества целей качества программного обеспечения (AGC)

Правила в SQO-Subset1

В Polyspace ® Code Prover™ следующий набор правил кодирования обычно уменьшает количество неподтвержденных результатов.

Номер правила

Описание

5.2

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

8.11

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

8.12

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

11.2

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

11.3

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

12.12

Базовые битовые представления значений с плавающей запятой не должны использоваться.

14.7

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

16.1

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

16.2

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

17.3

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

17.6

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

18.4

Профсоюзы не используются.

Для получения дополнительной информации об этих правилах см. Руководство MISRA AC AGC по применению MISRA-C:2004 в контексте автоматического создания кода.

Правила в SQO-Subset2

Оптимальные методы проектирования обычно приводят к снижению сложности кода, что может уменьшить количество недоказанных результатов в программе Polyspace Code Prover. Следующий набор правил кодирования обеспечивает применение оптимальных методов проектирования. SQO-subset2 опция проверяет правила в SQO-subset1 и некоторые дополнительные правила.

Номер правила

Описание

5.2

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

6.3

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

8.7

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

8.11

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

8.12

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

9.3

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

11.1

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

11.2

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

11.3

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

11.5

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

12.2

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

12.9

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

12.10

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

12.12

Базовые битовые представления значений с плавающей запятой не должны использоваться.

14.7

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

16.1

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

16.2

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

16.3

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

16.8

Все пути выхода из функции с типом возврата non-void должны иметь явную инструкцию return с выражением

16.9

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

17.3

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

17.6

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

18.4

Профсоюзы не используются.

19.9

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

19.10

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

19.11

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

19.12

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

20.3

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

Примечание

Программное обеспечение Polyspace не проверяет правило MISRA ® 20.3 напрямую.

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

int my_system_library_call(int in) {assert (in>1); if random \
return -1 else return 0; }

Для получения дополнительной информации об этих правилах см. Руководство MISRA AC AGC по применению MISRA-C:2004 в контексте автоматического создания кода.

См. также

Связанные темы