Polyspace Code Prover™ может проверить ваш код по большинству MISRA® C:2012 правила кодирования и некоторые директивы. Перечисленные подгруппы сопоставлены с различными подмножествами, описанными в MISRA C®: 2012 руководство. Можно активировать различные подмножества правил, используя Check MISRA C:2012 (-misra3) опция анализа.
MISRA C:2012 Dir 1.1 | Любое определяемое реализацией поведение, от которого зависит выход программы, должно быть задокументировано и понято |
MISRA C:2012 Dir 2.1 | Все исходные файлы должны компилироваться без каких-либо ошибок компиляции |
MISRA C:2012 Dir 4.1 | Отказы во время работы должны быть сведены к минимуму |
MISRA C:2012 Dir 4.3 | Язык сборки должен быть инкапсулирован и изолирован |
MISRA C:2012 Dir 4.4 | Разделы кода не должны быть «закомментированы» |
MISRA C:2012 Dir 4.5 | Идентификаторы в пространстве с тем же именем с перекрывающейся видимостью должны быть типографски однозначными |
MISRA C:2012 Dir 4.6 | typedefs которые указывают на размер и сигнальность, должны использоваться вместо основных числовых типов |
MISRA C:2012 Dir 4.8 | Если указатель на структуру или объединение никогда не дереферируется в модуле преобразования, то реализация объекта должна быть скрыта |
MISRA C:2012 Dir 4.9 | Функция должна использоваться в выборе функционального макроса, где они взаимозаменяемы |
MISRA C:2012 Dir 4.10 | Необходимо принять меры предосторожности, порядок предотвратить включение содержимого файла заголовка более одного раза |
MISRA C:2012 Dir 4.11 | Проверяется валидность значений, переданных в библиотечные функции |
MISRA C:2012 Dir 4.12 | Динамическое выделение памяти не должно использоваться |
MISRA C:2012 Rule 1.1 | Программа не должна содержать нарушений стандартного синтаксиса C и ограничений и не должна превышать пределов перевода реализации |
MISRA C:2012 Rule 1.2 | Языковые расширения не должны использоваться |
MISRA C:2012 Rule 1.3 | Не должно быть вхождения неопределенного или критического неопределенного поведения |
MISRA C:2012 Rule 1.4 | Функции Emergent Language не должны использоваться |
MISRA C:2012 Rule 2.1 | Проект не должен содержать недостижимый код |
MISRA C:2012 Rule 2.2 | Мертвого кода не должно быть |
MISRA C:2012 Rule 2.3 | Проект не должен содержать неиспользованных объявлений типов |
MISRA C:2012 Rule 2.4 | Проект не должен содержать неиспользованных объявлений тегов |
MISRA C:2012 Rule 2.5 | Проект не должен содержать неиспользованных объявлений макросов |
MISRA C:2012 Rule 2.6 | Функция не должна содержать неиспользованных объявлений меток |
MISRA C:2012 Rule 2.7 | В функциях не должно быть неиспользованных параметров |
MISRA C:2012 Rule 3.1 | Последовательности символов /* и // не может использоваться в комментарии |
MISRA C:2012 Rule 3.2 | Сращивание линий не должно использоваться в // комментарии |
MISRA C:2012 Rule 4.1 | Восьмиугольные и шестнадцатеричные выходные последовательности должны быть прекращены |
MISRA C:2012 Rule 4.2 | Триграфы не должны использоваться |
MISRA C:2012 Rule 5.1 | Внешние идентификаторы должны быть различными |
MISRA C:2012 Rule 5.2 | Идентификаторы, объявленные в тех же возможностях и пространстве имен, должны быть различными |
MISRA C:2012 Rule 5.3 | Идентификатор, объявленный во внутренних возможностях, не должен скрывать идентификатор, объявленный во внешних возможностях |
MISRA C:2012 Rule 5.4 | Идентификаторы макросов должны быть различными |
MISRA C:2012 Rule 5.5 | Идентификаторы должны отличаться от макросов имен |
MISRA C:2012 Rule 5.6 | Имя typedef должно быть уникальным идентификатором |
MISRA C:2012 Rule 5.7 | Имя тега должно быть уникальным идентификатором |
MISRA C:2012 Rule 5.8 | Идентификаторы, определяющие объекты или функции с внешним редактированием, должны быть уникальными |
MISRA C:2012 Rule 5.9 | Идентификаторы, которые определяют объекты или функции с внутренним редактированием, должны быть уникальными |
MISRA C:2012 Rule 6.1 | Битовые поля должны быть объявлены только с соответствующим типом |
MISRA C:2012 Rule 6.2 | Однобитовые именованные битовые поля не должны иметь тип со знаком |
MISRA C:2012 Rule 7.1 | Восьмиугольные константы не должны использоваться |
MISRA C:2012 Rule 7.2 | Суффикс «u» или «U» применяется ко всем целочисленным константам, которые представлены в беззнаковом типе |
MISRA C:2012 Rule 7.3 | Строчный символ «l» не должен использоваться в буквальном суффиксе |
MISRA C:2012 Rule 7.4 | Строковый литерал не должен назначаться объекту, если тип объекта не является «указателем на квалифицированный char» |
MISRA C:2012 Rule 8.1 | Типы должны быть четко указаны |
MISRA C:2012 Rule 8.2 | Типы функций должны быть в форме прототипа с именованными параметрами |
MISRA C:2012 Rule 8.3 | Во всех объявлениях объекта или функции должны использоваться одинаковые имена и типы классификаторов |
MISRA C:2012 Rule 8.4 | Совместимое объявление должно быть видно, когда определен объект или функция с внешним редактированием |
MISRA C:2012 Rule 8.5 | Внешний объект или функция должны быть объявлены один раз в одном и только одном файле |
MISRA C:2012 Rule 8.6 | Идентификатор с внешним редактированием должен иметь только одно внешнее определение |
MISRA C:2012 Rule 8.7 | Функции и объекты не должны быть определены с помощью внешнего редактирования, если они указаны только в одном модуле преобразования |
MISRA C:2012 Rule 8.8 | Спецификатор класса памяти должен использоваться во всех декларациях объектов и функций, имеющих внутреннее редактирование |
MISRA C:2012 Rule 8.9 | Объект должен быть определен в возможности, если его идентификатор появляется только в одной функции |
MISRA C:2012 Rule 8.10 | Встроенная функция должна быть объявлена статическим классом памяти |
MISRA C:2012 Rule 8.11 | Когда массив с внешним редактированием объявлен, его размер должен быть явно задан |
MISRA C:2012 Rule 8.12 | В списке перечислителей значение неявно заданной постоянной перечисления должно быть уникальным |
MISRA C:2012 Rule 8.13 | Указатель должен указывать на const-квалифицированный тип, когда это возможно |
MISRA C:2012 Rule 8.14 | Классификатор типа ограничения не должен использоваться |
MISRA C:2012 Rule 9.1 | Значение объекта с автоматической длительностью хранения не должно считываться до того, как оно установлено |
MISRA C:2012 Rule 9.2 | Инициализатор агрегата или объединения должен быть заключен в скобки |
MISRA C:2012 Rule 9.3 | Массивы не должны быть частично инициализированы |
MISRA C:2012 Rule 9.4 | Элемент объекта не должен быть инициализирован более одного раза |
MISRA C:2012 Rule 9.5 | Когда назначенные инициализаторы используются для инициализации объекта массива, размер массива должен задаваться явным образом |
MISRA C:2012 Rule 10.1 | Операнды не должны быть неуместного типа |
MISRA C:2012 Rule 10.2 | Выражения по существу типа символов не должны использоваться ненадлежащим образом в операциях сложения и вычитания |
MISRA C:2012 Rule 10.3 | Значение выражения не должно присваиваться объекту с более узким существенным типом или другой категории существенного типа |
MISRA C:2012 Rule 10.4 | Оба операнда оператора, в которых выполняются обычные арифметические преобразования, должны иметь одну и ту же категорию основных типов |
MISRA C:2012 Rule 10.5 | Значение выражения не должно быть приведено к неподходящему существенному типу |
MISRA C:2012 Rule 10.6 | Значение составного выражения не должно присваиваться объекту с более широким существенным типом |
MISRA C:2012 Rule 10.7 | Если составное выражение используется в качестве одного операнда оператора, в котором выполняются обычные арифметические преобразования, то другой операнд не должен иметь более широкого существенного типа |
MISRA C:2012 Rule 10.8 | Значение составного выражения не должно быть приведено к другой категории основных типов или к более широкому типу |
MISRA C:2012 Rule 11.1 | Преобразование не должно выполняться между указателем на функцию и любым другим типом |
MISRA C:2012 Rule 11.2 | Преобразование не должно выполняться между указателем на неполный тип и любым другим типом |
MISRA C:2012 Rule 11.3 | Приведение не должно выполняться между указателем на тип объекта и указателем на другой тип объекта |
MISRA C:2012 Rule 11.4 | Преобразование не должно выполняться между указателем на объект и целый тип |
MISRA C:2012 Rule 11.5 | Преобразование не должно выполняться из указателя в пустой в указатель на объект |
MISRA C:2012 Rule 11.6 | Приведение не должно выполняться между указателем на пустоту и арифметическим типом |
MISRA C:2012 Rule 11.7 | Приведение не должно выполняться между указателем на объект и нецелочисленным арифметическим типом |
MISRA C:2012 Rule 11.8 | Приведение не должно удалять какую-либо несовпадающую или летучую проверку из типа, на который указывает указатель |
MISRA C:2012 Rule 11.9 | Макрос NULL должен быть единственно разрешенной формой целочисленной нулевой константы указателя |
MISRA C:2012 Rule 12.1 | Приоритет операторов в выражениях должен быть сделан явным |
MISRA C:2012 Rule 12.2 | Операнд правой руки оператора сдвига должен находиться в области значений от нуля до единицы меньше ширины в битах существенного типа операнда левой руки |
MISRA C:2012 Rule 12.3 | Оператор запятыми не должен использоваться |
MISRA C:2012 Rule 12.4 | Оценка постоянных выражений не должна приводить к беззнаковому целочисленному переносу |
MISRA C:2012 Rule 12.5 | The sizeof оператор не должен иметь операнд, который является параметром функции, объявленным как «массив типа» |
MISRA C:2012 Rule 13.1 | Списки инициализаторов не должны содержать стойких побочных эффектов |
MISRA C:2012 Rule 13.2 | Значение выражения и его стойких побочных эффектов должно быть одинаковым при всех разрешенных порядках |
MISRA C:2012 Rule 13.3 | Полное выражение, содержащее оператор шага (+ +) или декремента (--), не должно иметь других потенциальных побочных эффектов, кроме тех, которые вызваны оператором шага или декремента |
MISRA C:2012 Rule 13.4 | Результат оператора назначения не должен использоваться |
MISRA C:2012 Rule 13.5 | Операнд правой руки логического & & или || оператора не должен содержать стойких побочных эффектов |
MISRA C:2012 Rule 13.6 | Операнд оператора sizeof не должен содержать никаких выражений, которые имеют потенциальные побочные эффекты |
MISRA C:2012 Rule 14.1 | Счетчик цикла не должен иметь по существу плавающего типа |
MISRA C:2012 Rule 14.2 | A для цикла должна быть хорошо сформирована |
MISRA C:2012 Rule 14.3 | Управляющие выражения не должны быть инвариантными |
MISRA C:2012 Rule 14.4 | Управляющее выражение оператора if и управляющее выражение оператора итерации должны иметь по существу логический тип |
MISRA C:2012 Rule 15.1 | Оператор goto не должен использоваться |
MISRA C:2012 Rule 15.2 | Оператор goto должен перейти к метке, объявленной позже в той же функции |
MISRA C:2012 Rule 15.3 | Любая метка, на которую ссылается оператор goto, должна быть объявлена в том же блоке или в любом блоке, содержащем оператор goto |
MISRA C:2012 Rule 15.4 | Не должно быть более одного оператора break или goto, используемого для завершения любого оператора итерации |
MISRA C:2012 Rule 15.5 | Функция должна иметь одну точку выхода в конце |
MISRA C:2012 Rule 15.6 | Тело итерационного оператора или селекционного оператора должно быть составным оператором |
MISRA C:2012 Rule 15.7 | Все, если... другое, если конструкции должны быть завершены оператором else |
MISRA C:2012 Rule 16.1 | Все операторы switch должны быть хорошо сформированы |
MISRA C:2012 Rule 16.2 | Метка switch должна использоваться только в том случае, если наиболее близко заключенный составной оператор является телом оператора switch |
MISRA C:2012 Rule 16.3 | Оператор безоговорочного пропуска прекращает действие каждого пункта switch |
MISRA C:2012 Rule 16.4 | Каждый оператор switch должен иметь метку по умолчанию |
MISRA C:2012 Rule 16.5 | Метка по умолчанию должна отображаться как первая или последняя метка switch оператора switch |
MISRA C:2012 Rule 16.6 | Каждый оператор switch должен иметь как минимум два положения switch |
MISRA C:2012 Rule 16.7 | Выражение switch не должно иметь по существу логического типа |
MISRA C:2012 Rule 17.1 | Функции < stdarg.h > не должны использоваться |
MISRA C:2012 Rule 17.2 | Функции не должны вызывать себя, прямо или косвенно |
MISRA C:2012 Rule 17.3 | Функция не должна объявляться неявно |
MISRA C:2012 Rule 17.4 | Все выходные пути из функции с непустым типом возврата должны иметь явный оператор возврата с выражением |
MISRA C:2012 Rule 17.5 | Аргумент функции, относящийся к параметру, объявленному как имеющий тип массива, должен иметь соответствующее количество элементов |
MISRA C:2012 Rule 17.6 | Объявление параметра массива не должно содержать статического ключевого слова между [] |
MISRA C:2012 Rule 17.7 | Должно использоваться значение, возвращаемое функцией, не имеющей пустого типа возврата |
MISRA C:2012 Rule 17.8 | Параметр функции не должен быть изменен |
MISRA C:2012 Rule 18.1 | Указатель, полученный из арифметики на операнде указателя, должен адресовать элемент того же массива, что и этот операнд указателя |
MISRA C:2012 Rule 18.2 | Вычитание между указателями должно применяться только к указателям, которые адресуют элементы одного массива |
MISRA C:2012 Rule 18.3 | Реляционные операторы >, > =, < и < = не должны применяться к объектам типа указателя, кроме тех случаев, когда они указывают на один и тот же объект |
MISRA C:2012 Rule 18.4 | Операторы +, -, + = и - = не должны применяться к выражению типа указателя |
MISRA C:2012 Rule 18.5 | Объявления должны содержать не более двух уровней вложения указателей |
MISRA C:2012 Rule 18.6 | Адрес объекта с автоматическим хранением не должен копироваться в другой объект, сохраняющийся после прекращения существования первого объекта |
MISRA C:2012 Rule 18.7 | Гибкие представители массива не должны быть объявлены |
MISRA C:2012 Rule 18.8 | Типы массивов переменной длины не должны использоваться |
MISRA C:2012 Rule 19.1 | Объект не должен быть назначен или скопирован в перекрывающийся объект |
MISRA C:2012 Rule 19.2 | Ключевое слово объединения не должно использоваться |
MISRA C:2012 Rule 20.1 | Директивам # include должны предшествовать только директивы предпроцессора или комментарии |
MISRA C:2012 Rule 20.2 | '", или\символы и/* или/последовательности символов не должны находиться в имени файла заголовка |
MISRA C:2012 Rule 20.3 | Директива # include должна сопровождаться последовательностью < filename > или «filename» |
MISRA C:2012 Rule 20.4 | Макрос не должен быть определен с таким же именем, как ключевое слово |
MISRA C:2012 Rule 20.5 | # undef не должен использоваться |
MISRA C:2012 Rule 20.6 | Лексемы, которые выглядят как директива предварительной обработки, не должны происходить в макросе аргумента |
MISRA C:2012 Rule 20.7 | Выражения, следующие из расширения макро- параметры, заключаются в круглые скобки |
MISRA C:2012 Rule 20.8 | Управляющее выражение директивы предварительной обработки # if или # elif должно вычисляться равным 0 или 1 |
MISRA C:2012 Rule 20.9 | Все идентификаторы, используемые в управляющем выражении директивы предварительной обработки # if или # elif, должны быть # defined d перед оценкой |
MISRA C:2012 Rule 20.10 | Операторы предпроцессора # и # не должны использоваться |
MISRA C:2012 Rule 20.11 | Макропараметр, непосредственно следующий за оператором #, не должен немедленно сопровождаться оператором # # |
MISRA C:2012 Rule 20.12 | Параметр макроса, используемый в качестве операнда операторам # или # #, который сам подлежит дальнейшей замене макросом, должен использоваться только в качестве операнда этим операторам |
MISRA C:2012 Rule 20.13 | Линии, чья первая лексема #, будет действительной директивой предварительной обработки |
MISRA C:2012 Rule 20.14 | Все директивы # else, # elif и # endif предпроцессора должны находиться в том же файле, что и директива # if, # ifdef или # ifndef, с которой они связаны |
MISRA C:2012 Rule 21.1 | # define и # undef не должны использоваться в зарезервированном идентификаторе или зарезервированном имени макроса |
MISRA C:2012 Rule 21.2 | Зарезервированный идентификатор или имя зарезервированного макроса не должны объявляться |
MISRA C:2012 Rule 21.3 | Функции выделения и отмены выделения памяти <stdlib.h> не может использоваться |
MISRA C:2012 Rule 21.4 | Стандартный файл заголовка < setjmp.h > не должен использоваться |
MISRA C:2012 Rule 21.5 | Стандартный файл заголовка < signal.h > не должен использоваться |
MISRA C:2012 Rule 21.6 | Входные/выходные функции Стандартной библиотеки не должны использоваться |
MISRA C:2012 Rule 21.7 | Стандартная библиотека функционирует atof, atoi, atol, и atoll функции <stdlib.h> не может использоваться |
MISRA C:2012 Rule 21.8 | Стандартные функции библиотеки abort, exit, getnenv и system от <stdlib.h> не может использоваться |
MISRA C:2012 Rule 21.9 | Библиотека Standard Library функционирует bsearch и qsort от <stdlib.h> не может использоваться |
MISRA C:2012 Rule 21.10 | Функции времени и даты Стандартной библиотеки не должны использоваться |
MISRA C:2012 Rule 21.11 | Стандартный файл заголовка < tgmath.h > не должен использоваться |
MISRA C:2012 Rule 21.12 | Особые функции обработки исключений <fenv.h> не должен использоваться |
MISRA C:2012 Rule 21.15 | Аргументы указателя на функции Стандартной библиотеки memcpy, memmove и memcmp должны быть указателями на квалифицированные или неквалифицированные версии совместимых типов |
MISRA C:2012 Rule 21.16 | Аргументы указателя на функцию Standard Library memcmp должен указывать либо на тип указателя, по существу на тип со знаком, по существу беззнаковый тип, по существу на логический тип или по существу на тип перечисления |
MISRA C:2012 Rule 22.5 | Указатель на FILE объект не должен быть разграниченным |
MISRA C:2012 шашки Polyspace
См. обзор поддержки Polyspace для стандарта C:2012 MISRA.
Проверяйте на нарушения стандарта кодирования
Проверка на нарушения AUTOSAR C++ 14, CERT® C, CERT C++ MISRA C, MISRA C++, JSF AV C++ или ISO-17961 стандарт с Bug Finder или Code Prover.
Целевые подмножества качества программного обеспечения (C:2012)
Смотрите, какие правила C:2012 MISRA снижают сложность кода и уменьшают количество недоказанных проверок в Code Prover.
Избегайте нарушений правил C:2012 MISRA 8.x
Избегайте конфликтующих объявлений или непреднамеренного изменения переменных.
Основные типы в C:2012 MISRA Rules 10.x
Узнайте, как правила C:2012 MISRA 10.x рассматривают определенные типы данных как по существу сходные.
1. Если смысл перевода понятен, то лучше оставьте как есть и не придирайтесь к словам, синонимам и тому подобному. О вкусах не спорим.
2. Не дополняйте перевод комментариями “от себя”. В исправлении не должно появляться дополнительных смыслов и комментариев, отсутствующих в оригинале. Такие правки не получится интегрировать в алгоритме автоматического перевода.
3. Сохраняйте структуру оригинального текста - например, не разбивайте одно предложение на два.
4. Не имеет смысла однотипное исправление перевода какого-то термина во всех предложениях. Исправляйте только в одном месте. Когда Вашу правку одобрят, это исправление будет алгоритмически распространено и на другие части документации.
5. По иным вопросам, например если надо исправить заблокированное для перевода слово, обратитесь к редакторам через форму технической поддержки.
