MISRA C:2012 命令およびルール

Polyspace™ でサポートされている MISRA C®:2012 コーディング ガイドラインのリストと説明

Polyspace では、MISRA C:2012 コーディング ルールと一部の命令に対してコードをチェックできます。リストされたサブグループは MISRA C:2012 ガイドラインに記載されたさまざまなサブセットに対応しています。Check MISRA C:2012 (-misra3) 解析オプションを使用して、このルールのサブセットを有効にします。MISRA C:2012 ガイドラインに違反すると、Polyspace により違反したルールまたは命令に関する情報を含むメッセージが提供されます。ほとんどの違反は解析のコンパイル段階で検出されます。

各ガイドラインは必須、必要、推奨というカテゴリのうち 1 つに分類されます。ルール チェックを設定する場合、これらのチェックすべきカテゴリのサブセットを選択できます。自動的に生成されたコードでは、一部のルールがカテゴリを変更します。追加カテゴリである可読性への変更が含まれます。生成されたコードの要件を使用 (-misra3-agc-mode)オプションは自動的に生成されたコードの分類を有効にします。

Polyspace により定義された MISRA® C:2012 ガイドラインには追加サブセットがあります。このガイドラインは SQO (ソフトウェア品質目標) と呼ばれ、直接または間接的に結果の精度に影響を与えます。コード チェックを設定するときに、これらのサブセットを選択できます。MISRA コーディング規約のソフトウェア品質目標サブセットを参照してください。MISRA C:2012 に対する Polyspace の対応範囲を確認するには、Polyspace でのコーディング規約のサポートを参照してください。

C11 や C17/C18 など、C 言語の特定のバージョンを使用している場合、MISRA C:2012 違反をより正確にチェックするため、C バージョンを指定します。C 標準バージョン (-c-version) を参照してください。

Polyspace 結果

すべて展開する

MISRA C:2012 Dir 1.1Any implementation-defined behavior on which the output of the program depends shall be documented and understood
MISRA C:2012 Dir 2.1All source files shall compile without any compilation errors
MISRA C:2012 Dir 4.1Run-time failures shall be minimized
MISRA C:2012 Dir 4.3Assembly language shall be encapsulated and isolated
MISRA C:2012 Dir 4.4Sections of code should not be "commented out"
MISRA C:2012 Dir 4.5Identifiers in the same name space with overlapping visibility should be typographically unambiguous
MISRA C:2012 Dir 4.6基本数値型の代わりに、サイズと符号属性を示す typedefs を使用する必要があります。
MISRA C:2012 Dir 4.7If a function returns error information, then that error information shall be tested
MISRA C:2012 Dir 4.8If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden
MISRA C:2012 Dir 4.9A function should be used in preference to a function-like macro where they are interchangeable
MISRA C:2012 Dir 4.10Precautions shall be taken in order to prevent the contents of a header file being included more than once
MISRA C:2012 Dir 4.11The validity of values passed to library functions shall be checked
MISRA C:2012 Dir 4.12Dynamic memory allocation shall not be used
MISRA C:2012 Dir 4.13Functions which are designed to provide operations on a resource should be called in an appropriate sequence
MISRA C:2012 Dir 4.14The validity of values received from external sources shall be checked
MISRA C:2012 Dir 4.15Evaluation of floating-point expressions shall not lead to the undetected generation of infinities and NaNs (R2024a 以降)
MISRA C:2012 Dir 5.1There shall be no data races between threads (R2024b 以降)
MISRA C:2012 Dir 5.2There shall be no deadlocks between threads (R2024b 以降)
MISRA C:2012 Dir 5.3There shall be no dynamic thread creation (R2025b 以降)
MISRA C:2012 Rule 1.1The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation’s translation limits
MISRA C:2012 Rule 1.2Language extensions should not be used
MISRA C:2012 Rule 1.3There shall be no occurrence of undefined or critical unspecified behaviour
MISRA C:2012 Rule 1.4Emergent language features shall not be used
MISRA C:2012 Rule 1.5Obsolescent language features shall not be used (R2024a 以降)
MISRA C:2012 Rule 1.5Obsolescent language features shall not be used (R2024a 以降)
MISRA C:2012 Rule 2.1A project shall not contain unreachable code
MISRA C:2012 Rule 2.2A project shall not contain dead code
MISRA C:2012 Rule 2.3A project should not contain unused type declarations
MISRA C:2012 Rule 2.4A project should not contain unused tag declarations
MISRA C:2012 Rule 2.5A project should not contain unused macro definitions
MISRA C:2012 Rule 2.6A function should not contain unused label declarations
MISRA C:2012 Rule 2.7A function should not contain unused parameters
MISRA C:2012 Rule 2.8A project should not contain unused object definitions (R2024b 以降)
MISRA C:2012 Rule 3.1The character sequences /* and // shall not be used within a comment.
MISRA C:2012 Rule 3.2Line-splicing shall not be used in // comments.
MISRA C:2012 Rule 4.1Octal and hexadecimal escape sequences shall be terminated
MISRA C:2012 Rule 4.2Trigraphs should not be used
MISRA C:2012 Rule 5.1External identifiers shall be distinct
MISRA C:2012 Rule 5.2Identifiers declared in the same scope and name space shall be distinct
MISRA C:2012 Rule 5.3An identifier declared in an inner scope shall not hide an identifier declared in an outer scope
MISRA C:2012 Rule 5.4Macro identifiers shall be distinct
MISRA C:2012 Rule 5.5Identifiers shall be distinct from macro names
MISRA C:2012 Rule 5.6A typedef name shall be a unique identifier
MISRA C:2012 Rule 5.7A tag name shall be a unique identifier
MISRA C:2012 Rule 5.8Identifiers that define objects or functions with external linkage shall be unique
MISRA C:2012 Rule 5.9Identifiers that define objects or functions with internal linkage should be unique
MISRA C:2012 Rule 6.1Bit-fields shall only be declared with an appropriate type
MISRA C:2012 Rule 6.2Single-bit named bit-fields shall not be of a signed type
MISRA C:2012 Rule 6.3A bit field shall not be declared as a member of a union (R2024a 以降)
MISRA C:2012 Rule 7.1Octal constants shall not be used
MISRA C:2012 Rule 7.2A “u” or “U” suffix shall be applied to all integer constants that are represented in an unsigned type
MISRA C:2012 Rule 7.3The lowercase character “l” shall not be used in a literal suffix
MISRA C:2012 Rule 7.4A string literal shall not be assigned to an object unless the object’s type is “pointer to const-qualified char”
MISRA C:2012 Rule 7.5The argument of an integer constant macro shall have an appropriate form (R2024a 以降)
MISRA C:2012 Rule 7.6The small integer variants of the minimum-width integer constant macros shall not be used (R2025a 以降)
MISRA C:2012 Rule 8.1Types shall be explicitly specified
MISRA C:2012 Rule 8.2Function types shall be in prototype form with named parameters
MISRA C:2012 Rule 8.3All declarations of an object or function shall use the same names and type qualifiers
MISRA C:2012 Rule 8.4A compatible declaration shall be visible when an object or function with external linkage is defined
MISRA C:2012 Rule 8.5An external object or function shall be declared once in one and only one file
MISRA C:2012 Rule 8.6An identifier with external linkage shall have exactly one external definition
MISRA C:2012 Rule 8.7Functions and objects should not be defined with external linkage if they are referenced in only one translation unit
MISRA C:2012 Rule 8.8The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage
MISRA C:2012 Rule 8.9An object should be declared at block scope if its identifier only appears in a single function
MISRA C:2012 Rule 8.10An inline function shall be declared with the static storage class
MISRA C:2012 Rule 8.11When an array with external linkage is declared, its size should be explicitly specified
MISRA C:2012 Rule 8.12Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique
MISRA C:2012 Rule 8.13A pointer should point to a const-qualified type whenever possible
MISRA C:2012 Rule 8.14The restrict type qualifier shall not be used
MISRA C:2012 Rule 8.15All declarations of an object with an explicit alignment specification shall specify the same alignment (R2024a 以降)
MISRA C:2012 Rule 8.16The alignment specification of zero should not appear in an object declaration (R2024a 以降)
MISRA C:2012 Rule 8.17At most one explicit alignment specifier should appear in an object declaration (R2024a 以降)
MISRA C:2012 Rule 9.1The value of an object with automatic storage duration shall not be read before it has been set
MISRA C:2012 Rule 9.2The initializer for an aggregate or union shall be enclosed in braces
MISRA C:2012 Rule 9.3Arrays shall not be partially initialized
MISRA C:2012 Rule 9.4An element of an object shall not be initialized more than once
MISRA C:2012 Rule 9.5Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly
MISRA C:2012 Rule 9.6An initializer using chained designators shall not contain initializers without designators (R2025a 以降)
MISRA C:2012 Rule 9.7Atomic objects shall be appropriately initialized before being accessed (R2025b 以降)
MISRA C:2012 Rule 10.1Operands shall not be of an inappropriate essential type
MISRA C:2012 Rule 10.2Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations
MISRA C:2012 Rule 10.3The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category
MISRA C:2012 Rule 10.4Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category
MISRA C:2012 Rule 10.5The value of an expression should not be cast to an inappropriate essential type
MISRA C:2012 Rule 10.6The value of a composite expression shall not be assigned to an object with wider essential type
MISRA C:2012 Rule 10.7If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type
MISRA C:2012 Rule 10.8The value of a composite expression shall not be cast to a different essential type category or a wider essential type
MISRA C:2012 Rule 11.1Conversions shall not be performed between a pointer to a function and any other type
MISRA C:2012 Rule 11.2Conversions shall not be performed between a pointer to an incomplete type and any other type
MISRA C:2012 Rule 11.3A conversion shall not be performed between a pointer to object type and a pointer to a different object type
MISRA C:2012 Rule 11.4A conversion should not be performed between a pointer to object and an integer type
MISRA C:2012 Rule 11.5A conversion should not be performed from pointer to void into pointer to object
MISRA C:2012 Rule 11.6A cast shall not be performed between pointer to void and an arithmetic type
MISRA C:2012 Rule 11.7A cast shall not be performed between pointer to object and a non-integer arithmetic type
MISRA C:2012 Rule 11.8A conversion shall not remove any const, volatile or _Atomic qualification from the type pointed to by a pointer
MISRA C:2012 Rule 11.9The macro NULL shall be the only permitted form of integer null pointer constant
MISRA C:2012 Rule 11.10The _Atomic qualifier shall not be applied to the incomplete type void (R2024b 以降)
MISRA C:2012 Rule 12.1The precedence of operators within expressions should be made explicit
MISRA C:2012 Rule 12.2The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand
MISRA C:2012 Rule 12.3The comma operator should not be used
MISRA C:2012 Rule 12.4Evaluation of constant expressions should not lead to unsigned integer wrap-around
MISRA C:2012 Rule 12.5The sizeof operator shall not have an operand which is a function parameter declared as “array of type”
MISRA C:2012 Rule 12.6Structure and union members of atomic objects shall not be directly accessed (R2025a 以降)
MISRA C:2012 Rule 13.1Initializer lists shall not contain persistent side effects
MISRA C:2012 Rule 13.2The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders and shall be independent from thread interleaving
MISRA C:2012 Rule 13.3A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator
MISRA C:2012 Rule 13.4The result of an assignment operator should not be used
MISRA C:2012 Rule 13.5The right hand operand of a logical && or || operator shall not contain persistent side effects
MISRA C:2012 Rule 13.6The operand of the sizeof operator shall not contain any expression which has potential side effects
MISRA C:2012 Rule 14.1A loop counter shall not have essentially floating type
MISRA C:2012 Rule 14.2A for loop shall be well-formed
MISRA C:2012 Rule 14.3Controlling expressions shall not be invariant
MISRA C:2012 Rule 14.4The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type
MISRA C:2012 Rule 15.1The goto statement should not be used
MISRA C:2012 Rule 15.2The goto statement shall jump to a label declared later in the same function
MISRA C:2012 Rule 15.3Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement
MISRA C:2012 Rule 15.4There should be no more than one break or goto statement used to terminate any iteration statement
MISRA C:2012 Rule 15.5A function should have a single point of exit at the end
MISRA C:2012 Rule 15.6The body of an iteration-statement or a selection-statement shall be a compound statement
MISRA C:2012 Rule 15.7All if … else if constructs shall be terminated with an else statement
MISRA C:2012 Rule 16.1All switch statements shall be well-formed
MISRA C:2012 Rule 16.2A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement
MISRA C:2012 Rule 16.3An unconditional break statement shall terminate every switch-clause
MISRA C:2012 Rule 16.4Every switch statement shall have a default label
MISRA C:2012 Rule 16.5A default label shall appear as either the first or the last switch label of a switch statement
MISRA C:2012 Rule 16.6Every switch statement shall have at least two switch-clauses
MISRA C:2012 Rule 16.7A switch-expression shall not have essentially Boolean type
MISRA C:2012 Rule 17.1The standard header file <stdarg.h> shall not be used
MISRA C:2012 Rule 17.2Functions shall not call themselves, either directly or indirectly
MISRA C:2012 Rule 17.3A function shall not be declared implicitly
MISRA C:2012 Rule 17.4All exit paths from a function with non-void return type shall have an explicit return statement with an expression
MISRA C:2012 Rule 17.5The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements
MISRA C:2012 Rule 17.6The declaration of an array parameter shall not contain the static keyword between the [ ]
MISRA C:2012 Rule 17.7The value returned by a function having non-void return type shall be used
MISRA C:2012 Rule 17.8A function parameter should not be modified
MISRA C:2012 Rule 17.9A function declared with a _Noreturn function specifier shall not return to its caller (R2024a 以降)
MISRA C:2012 Rule 17.10A function declared with a _Noreturn function specifier shall have void return type (R2024a 以降)
MISRA C:2012 Rule 17.11A function that never returns should be declared with a _Noreturn function specifier (R2024a 以降)
MISRA C:2012 Rule 17.12A function identifier should only be used with either a preceding &, or with a parenthesized parameter list (R2024a 以降)
MISRA C:2012 Rule 17.13A function type shall not be type qualified (R2024a 以降)
MISRA C:2012 Rule 18.1A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
MISRA C:2012 Rule 18.2Subtraction between pointers shall only be applied to pointers that address elements of the same array
MISRA C:2012 Rule 18.3The relational operators >, >=, < and <= shall not be applied to expressions of pointer type except where they point into the same object
MISRA C:2012 Rule 18.4The +, -, += and -= operators should not be applied to an expression of pointer type
MISRA C:2012 Rule 18.5Declarations should contain no more than two levels of pointer nesting
MISRA C:2012 Rule 18.6The address of an object with automatic or thread-local storage shall not be copied to another object that persists after the first object has ceased to exist
MISRA C:2012 Rule 18.7Flexible array members shall not be declared
MISRA C:2012 Rule 18.8Variable-length arrays shall not be used
MISRA C:2012 Rule 18.9An object with temporary lifetime shall not undergo array-to-pointer conversion (R2024a 以降)
MISRA C:2012 Rule 18.10Pointers to variably-modified array types shall not be used (R2025a 以降)
MISRA C:2012 Rule 19.1An object shall not be assigned or copied to an overlapping object
MISRA C:2012 Rule 19.2The union keyword should not be used
MISRA C:2012 Rule 20.1#include directives should only be preceded by preprocessor directives or comments
MISRA C:2012 Rule 20.2The ', " or \ characters and the /* or // character sequences shall not occur in a header file name
MISRA C:2012 Rule 20.3The #include directive shall be followed by either a <filename> or "filename" sequence
MISRA C:2012 Rule 20.4A macro shall not be defined with the same name as a keyword
MISRA C:2012 Rule 20.5#undef should not be used
MISRA C:2012 Rule 20.6Tokens that look like a preprocessing directive shall not occur within a macro argument
MISRA C:2012 Rule 20.7Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses
MISRA C:2012 Rule 20.8The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1
MISRA C:2012 Rule 20.9All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define’d before evaluation
MISRA C:2012 Rule 20.10The # and ## preprocessor operators should not be used
MISRA C:2012 Rule 20.11A macro parameter immediately following a # operator shall not immediately be followed by a ## operator
MISRA C:2012 Rule 20.12A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators
MISRA C:2012 Rule 20.13A line whose first token is # shall be a valid preprocessing directive
MISRA C:2012 Rule 20.14All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related
MISRA C:2012 Rule 21.1#define and #undef shall not be used on a reserved identifier or reserved macro name
MISRA C:2012 Rule 21.2A reserved identifier or reserved macro name shall not be declared
MISRA C:2012 Rule 21.3The memory allocation and deallocation functions of <stdlib.h> shall not be used
MISRA C:2012 Rule 21.4The standard header file <setjmp.h> shall not be used
MISRA C:2012 Rule 21.5The standard header file <signal.h> shall not be used
MISRA C:2012 Rule 21.6The Standard Library input/output functions shall not be used
MISRA C:2012 Rule 21.7The Standard Library functions atof, atoi, atol, and atoll functions of <stdlib.h> shall not be used
MISRA C:2012 Rule 21.8The Standard Library termination functions of <stdlib.h> shall not be used
MISRA C:2012 Rule 21.9The Standard Library library functions bsearch and qsort of <stdlib.h> shall not be used
MISRA C:2012 Rule 21.10The Standard Library time and date functions shall not be used
MISRA C:2012 Rule 21.11The standard header file <tgmath.h> should not be used
MISRA C:2012 Rule 21.12The standard header file <fenv.h> shall not be used
MISRA C:2012 Rule 21.13Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EOF
MISRA C:2012 Rule 21.14The Standard Library function memcmp shall not be used to compare null terminated strings
MISRA C:2012 Rule 21.15The pointer arguments to the Standard Library functions memcpy, memmove and memcmp shall be pointers to qualified or unqualified versions of compatible types
MISRA C:2012 Rule 21.16The pointer arguments to the Standard Library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type
MISRA C:2012 Rule 21.17Use of the string handling function from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters
MISRA C:2012 Rule 21.18The size_t argument passed to any function in <string.h> shall have an appropriate value
MISRA C:2012 Rule 21.19The pointers returned by the Standard Library functions localeconv, getenv, setlocale or strerror shall only be used as if they have pointer to const-qualified type
MISRA C:2012 Rule 21.20The pointer returned by the Standard Library functions asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale or strerror shall not be used following a subsequent call to the same function
MISRA C:2012 Rule 21.21The Standard Library function system of <stdlib.h> shall not be used (R2021a 以降)
MISRA C:2012 Rule 21.22All operand arguments to any type-generic macros declared in <tgmath.h> shall have an appropriate essential type (R2024a 以降)
MISRA C:2012 Rule 21.23All operand arguments to any multi-argument type-generic macros declared in <tgmath.h> shall have the same standard type (R2024a 以降)
MISRA C:2012 Rule 21.24The random number generator functions of <stdlib.h> shall not be used (R2024a 以降)
MISRA C:2012 Rule 21.25All memory synchronization operations shall be executed in sequentially consistent order (R2025a 以降)
MISRA C:2012 Rule 21.26The Standard Library function mtx_timedlock() shall only be invoked on mutex objects of appropriate mutex type (R2025b 以降)
MISRA C:2012 Rule 22.1All resources obtained dynamically by means of Standard Library functions shall be explicitly released
MISRA C:2012 Rule 22.2A block of memory shall only be freed if it was allocated by means of a Standard Library function
MISRA C:2012 Rule 22.3The same file shall not be open for read and write access at the same time on different streams
MISRA C:2012 Rule 22.4There shall be no attempt to write to a stream which has been opened as read-only
MISRA C:2012 Rule 22.5A pointer to a FILE object shall not be dereferenced
MISRA C:2012 Rule 22.6The value of a pointer to a FILE shall not be used after the associated stream has been closed
MISRA C:2012 Rule 22.7The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF
MISRA C:2012 Rule 22.8The value of errno shall be set to zero prior to a call to an errno-setting-function
MISRA C:2012 Rule 22.9The value of errno shall be tested against zero after calling an errno-setting function
MISRA C:2012 Rule 22.10The value of errno shall only be tested when the last function to be called was an errno-setting function
MISRA C:2012 Rule 22.11A thread that was previously either joined or detached shall not be subsequently joined nor detached (R2024b 以降)
MISRA C:2012 Rule 22.12Thread objects, thread synchronization objects, and thread-specific storage pointers shall only be accessed by the appropriate Standard Library functions (R2025b 以降)
MISRA C:2012 Rule 22.13Thread objects, thread synchronization objects and thread-specific storage pointers shall have appropriate storage duration (R2025a 以降)
MISRA C:2012 Rule 22.14Thread synchronization objects shall be initialized before being accessed (R2025b 以降)
MISRA C:2012 Rule 22.15Thread synchronization objects and thread-specific storage pointers shall not be destroyed until after all threads accessing them have terminated (R2024b 以降)
MISRA C:2012 Rule 22.16All mutex objects locked by a thread shall be explicitly unlocked by the same thread (R2024b 以降)
MISRA C:2012 Rule 22.17No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before (R2024b 以降)
MISRA C:2012 Rule 22.18Non-recursive mutexes shall not be recursively locked (R2025a 以降)
MISRA C:2012 Rule 22.19A condition variable shall be associated with at most one mutex object (R2025b 以降)
MISRA C:2012 Rule 22.20Thread-specific storage pointers shall be created before being accessed (R2025b 以降)
MISRA C:2012 Rule 23.1A generic selection should only be expanded from a macro (R2024a 以降)
MISRA C:2012 Rule 23.2A generic selection that is not expanded from a macro shall not contain potential side effects in the controlling expression (R2024a 以降)
MISRA C:2012 Rule 23.3A generic selection should contain at least one non-default association (R2024a 以降)
MISRA C:2012 Rule 23.4A generic association shall list an appropriate type (R2024a 以降)
MISRA C:2012 Rule 23.5A generic selection should not depend on implicit pointer type conversion (R2024a 以降)
MISRA C:2012 Rule 23.6The controlling expression of a generic selection shall have an essential type that matches its standard type (R2024a 以降)
MISRA C:2012 Rule 23.7A generic selection that is expanded from a macro should evaluate its argument only once (R2024a 以降)
MISRA C:2012 Rule 23.8A default association shall appear as either the first or the last association of a generic selection (R2024a 以降)

トピック

MISRA C:2012 に対する Polyspace のサポート

MISRA C:2012 サブセット

特定の MISRA C:2012 ルール