MISRA C:2012 Coding Standard Review

Amplification

Appendix G of MISRA C:2012 lists, for both C90 and C99, those implementation-defined behaviours that:

• Are considered to have the potential to cause unexpected program operation, and
• May be present in a program even if it complies with all the other MISRA C guidelines.

All of these implementation-defined behaviours on which the program output depends must be:

• Documented, and
• Understood by developers.

Note: a conforming implementation is required to document its treatment of all implementation-defined behaviour. The developer of an implementation should be consulted if any documentation is missing.

Amplification

The rationale for the use of the assembly language and the mechanism for interfacing between C and the assembly language shall be documented.

Amplification

Where assembly language instructions are used they shall be encapsulated and isolated in:

• Assembly language functions;
• C functions (inline functions preferred for C99);
• C macros.

Amplification

This rule applies to both // and /* ... */ styles of comment.

Amplification

The definition of the term "unambiguous" should be determined for a project taking into account the alphabet and language in which the source code is being written.

For the Latin alphabet as used in English words, it is advised as a minimum that identifiers should not differ by any combination of:

• The interchange of a lowercase character with its uppercase equivalent;
• The presence or absence of the underscore character;
• The interchange of the letter "O", and the digit "0";
• The interchange of the letter "I", and the digit "1";
• The interchange of the letter "I", and the letter "l" (el);
• The interchange of the letter "l" (el), and the digit "1";
• The interchange of the letter "S", and the digit "5";
• The interchange of the letter "Z", and the digit "2";
• The interchange of the letter "n", and the letter "h";
• The interchange of the letter "B", and the digit "8";
• The interchange of the letter sequence "rn" ("r" followed by "n"), and the letter "m";

Amplification

The basic numerical types of char, short, int, long, long long (C99), float, double and long double (C99) should not be used, but specific-length typedefs should be used.

For C99, the types provided by <stdint.h> should be used. For C90, equivalent types should be defined and used.

A type must not be defined with a specific length unless the implemented type is actually of that length.

It is not necessary to use typedefs in the declaration of bit-fields.

For example, on a 32-bit C90 implementation the following definitions might be suitable:

   
   typedef signed   char   int8_t;
   typedef signed   short  int16_t;
   typedef signed   int    int32_t;
   typedef signed   long   int64_t;
   typedef unsigned char   uint8_t;
   typedef unsigned short  uint16_t;
   typedef unsigned int    uint32_t;
   typedef unsigned long   uint64_t;
   typedef          float  float32_t;
   typedef          double float64_t;
   typedef long     double float128_t;

Exception

1. The basic numerical types may be used in a typedef to define a specific-length type.
2. For function "main" an int may be used rather than the typedefs as a return type. Therefore int main (void) is permitted.
3. For function "main" an int may be used rather than the typedefs for the input parameter argc.
4. For function "main" a char may be used rather than the typedefs for the input parameter argv.

Therefore int main( int argc, char *argv[] ) is permitted (C99 Section 5.1.2.2.1).

Amplification

The list of functions that are deemed to return error information shall be determined by the project.

The error information returned by a function shall be tested in a meaningful manner.

Exception

If it can be shown, for example by checking arguments, that a function cannot return an error indication then there is no need to perform a check.

Amplification

The implementation of an object should be hidden by means of a pointer to an incomplete type.

Amplification

This guideline applies only where a function is permitted by the syntax and constraints of the language standard.

Amplification

The nature and organisation of the project will determine which libraries, and functions within those libraries, should be subject to this directive.

Amplification

This rule applies to all dynamic memory allocation packages including:

• Those provided by The Standard Library;
• 3rd party packages.

Amplification A set of functions providing operations on a resource typically has three kinds of operation:

1. allocation of the resource, e.g. opening a file
2. deallocation of the resource, e.g. closing a file
3. other operations, e.g. reading from a file

For each such set of functions, all uses of its operations should occur in an appropriate sequence.

Amplification

The program shall use only those features of the C language and its library that are specified in the chosen version of The Standard (see Section 3.1).

The Standard permits implementations to provide language extensions and the use of such extensions is permitted by this rule.

Except when making use of a language extension, a program shall not:

• Contain any violations of the language syntax described in The Standard;
• Contain any violations of the constraints imposed by The Standard.

A program shall not exceed the translation limits imposed by the implementation. The minimum translation limits are specified by The Standard but an implementation may provide higher limits.

Note: a conforming implementation generates a diagnostic for syntax and constraint violations but be aware that:

• The diagnostic need not necessarily be an error but could, for example, be a warning;
• The program may be translated and an executable generated despite the presence of a syntax or constraint violation;

Note: a conforming implementation does not need to generate a diagnostic when a translation limit is exceeded; an executable may be generated but it is not guaranteed to execute correctly.

Amplification

Some undefined and unspecified behaviours are dealt with by specific rules. This rule prevents all other undefined and critical unspecified behaviours. Appendix H lists the undefined behaviours and those unspecified behaviours that are considered critical.

Amplification

Any operation that is executed but whose removal would not affect program behaviour constitutes dead code. Operations that are introduced by language extensions are assumed always to have an effect on program behaviour.

Note: The behaviour of an embedded system is often determined not just by the nature of its actions, but also by the time at which they occur.

Note: unreachable code is not dead code as it cannot be executed.

Exception

A cast to void is assumed to indicate a value that is intentionally not being used. The cast is therefore not dead code itself. It is treated as using its operand which is therefore also not dead code.

Exception

The sequence // is permitted within a // comment.

Amplification

Line-splicing occurs when the \ character is immediately followed by a new-line character. If the source file contains multibyte characters, they are converted to the source character set before any splicing occurs.

Amplification

An octal or hexadecimal escape sequence shall be terminated by either:

• The start of another escape sequence, or
• The end of the character constant or the end of a string literal.

Amplification

This rule requires that different external identifiers be distinct within the limits imposed by the implementation.

The definition of distinct depends on the implementation and on the version of the C language that is being used:

• In C90 the minimum requirement is that the first 6 characters of external identifiers are significant but their case is not required to be significant;
• In C99 the minimum requirement is that the first 31 characters of external identifiers are significant, with each universal character or corresponding extended source character occupying between 6 and 10 characters.

In practice, many implementations provide greater limits. For example it is common for external identifiers in C90 to be case-sensitive and for at least the first 31 characters to be significant.

Amplification

This rule does not apply if both identifers are external identifers because this case is covered by Rule 5.1.

This rule does not apply if either identifer is a macro identifer because this case is covered by Rule 5.4 and Rule 5.5.

The definition of distinct depends on the implementation and on the version of the C language that is being used:

• In C90 the minimum requirement is that the first 31 characters are significant;
• In C99 the minimum requirement is that the first 63 characters are significant, with each universal character or extended source character counting as a single character;

Amplification

An identifier declared in an inner scope shall be distinct from any identifier declared in an outer scope.

The definition of distinct depends on the implementation and the version of the C language that is being used:

• In C90 the minimum requirement is that the first 31 characters are significant;
• In C99 the minimum requirement is that the first 63 characters are significant, with each universal character or extended source character counting as a single character.

Amplification

This rule requires that, when a macro is being defined, its name be distinct from:

• the names of the other macros that are currently defined; and
• the names of their parameters.

It also requires that the names of the parameters of a given macro be distinct from each other but does not require that macro parameters names be distinct across two different macros.

The definition of distinct depends on the implementation and on the version of the C language that is being used:

• In C90 the minimum requirement is that the first 31 characters of macro identifiers are significant;
• In C99 the minimum requirement is that the first 63 characters of macro identifiers are significant.

In practice, implementations may provide greater limits. This rule requires that macro identifiers be distinct within the limits imposed by the implementation.

Amplification

This rule requires that the names of macros that exist prior to preprocessing be distinct from the identifiers that exist after preprocessing. It applies to identifiers, regardless of scope or name space, and to any macros that have been defined regardless of whether the definition is still in force when the identifier is declared.

The definition of distinct depends on the implementation and the version of the C language that is being used:

• In C90 the minimum requirement is that the first 31 characters are significant;
• In C99 the minimum requirement is that the first 63 characters are significant, with each universal character or extended source character counting as a single character.

Amplification

A typedef name shall be unique across all name spaces and translation units. Multiple declarations of the same typedef name are only permitted by this rule if the type definition is made in a header file and that header file is included in multiple source files.

Exception

The typedef name may be the same as the structure, union or enumeration tag name associated with the typedef.

Amplification

The tag shall be unique across all name spaces and translation units.

All declarations of the tag shall specify the same type.

Multiple complete declarations of the same tag are only permitted by this rule if the tag is declared in a header file and that header file is included in multiple source files.

Exception

The tag name may be the same as the typedef name with which it is associated.

Amplification

An identifier used as an external identifier shall not be used for any other purpose in any name space or translation unit, even if it denotes an object with no linkage.

Amplification

The identifier name should be unique across all name spaces and translation units. Any identifier used in this way should not have the same name as any other identifier, even if that other identifier denotes an object with no linkage.

Exception

An inline function with internal linkage may be defined in more than one translation unit provided that all such definitions are made in the same header file that is included in each translation unit.

Amplification

The appropriate bit-field types are:

• C90: either unsigned int or signed int;
• C99: one of:
  • either unsigned int or signed int;
  • another explicitly signed or explicitly unsigned integer type that is permitted by the implementation;
  • _Bool.

Note: It is permitted to use typedefs to designate an appropriate type.

Exception

The integer constant zero (written as a single numeric digit), is strictly speaking an octal constant, but is a permitted exception to this rule.

Amplification

This rule applies to:

• Integer constants that appear in the controlling expressions of #if and #elif preprocessing directives;
• Any other integer constants that exist after preprocessing.

Note: during preprocessing, the type of an integer constant is determined in the same manner as after preprocessing except that:

• All signed integer types behave as if they were long (C90) or intmax_t (C99);
• All unsigned integer types behave as if they were unsigned long (C90) or uintmax_t (C99).

Amplification

No attempt shall be made to modify a string literal or wide string literal directly.

The result of the address-of operator, &, applied to a string literal shall not be assigned to an object unless that object's type is "pointer to array of const-qualifed char".

The same considerations apply to wide string literals. A wide string literal shall not be assigned to an object unless the object's type is "pointer to const-qualifed wchar_t". The result of the address-of operator, &, applied to a wide string literal shall not be assigned to an object unless that object's type is "pointer to array of const-qualifed wchar_t".

Amplification

Storage class specifiers are not included within the scope of this rule.

Exception

Compatible versions of the same basic type may be used interchangeably. For example, int, signed and signed int are all equivalent.

Amplification

A compatible declaration is one which declares a compatible type for the object or function being defined.

Amplification

This rule applies to non-defining declarations only.

Amplification

Since definitions are also declarations, this rule applies equally to definitions.

Amplification

This rule applies to non-defining declarations only. It is possible to define an array and specify its size implicitly by means of initialization.

Amplification

A pointer should point to a const-qualified type unless either:

• It is used to modify an object, or
• It is copied to another pointer that points to a type that is not const-qualified by means of either:
• Assignment, or
• Memory move or copying functions.

For the purposes of simplicity, this rule is written in terms of pointers and the types that they point to. However, it applies equally to arrays and the types of the elements that they contain. An array should have elements with const-qualified type unless either:

• Any element of the array is modified, or
• It is copied to a pointer that points to a type that is not const-qualified by the means described above.

Amplification

For the purposes of this rule, an array element or structure member shall be considered as a discrete object.

Amplification

This rule applies to initializers for both objects and subobjects.

An initializer of the form { 0 }, which sets all values to 0, may be used to initialize subobjects without nested braces.

Note: this rule does not itself require explicit initialization of objects or subobjects.

Exception

1. An array may be initialized using a string literal.
2. An automatic structure or union may be initialized using an expression with compatible structure or union type.
3. A designated initializer may be used to initialize part of a subobject.

Amplification

If any element of an array object or subobject is explicitly initialized, then the entire object or subobject shall be explicitly initialized.

Exception

1. An initializer of the form { 0 } may be used to explicitly initialise all elements of an array object or subobject.
2. An array whose initializer consists only of designated initializers may be used, for example to perform a sparse initialization.
3. An array initialized using a string literal does not need an initializer for every element.

Amplification

This rule applies to initializers for both objects and subobjects.

The provision of designated initializers in C99 allows the naming of the components of an aggregate (structure or array) or of a union to be initialized within an initializer list and allows the object's elements to be initialized in any order by specifying the array indices or structure field names they apply to (elements having no initialization value assume the default for uninitialized objects).

Amplification

The rule applies equally to an array subobject that is a flexible array member.

Amplification

In the following table a number within a cell indicates where a restriction applies to the use of an essential type as an operand to an operator. These numbers correspond to paragraphs in the Rationale section and indicate why each restriction is imposed.

Operator	Operand	Essential type category of arithmetic operand
		Boolean	character	enum	signed	unsigned	floating
[ ]	integer	3	4				1
+(unary)		3	4	5
-(unary)		3	4	5		8
+ -	either	3		5
* /	either	3	4	5
%	either	3	4	5			1
< > <= >=	either	3
== !=	either
! && ||	any		2	2	2	2	2
<< >>	left	3	4	5, 6	6		1
<< >>	right	3	4	7	7		1
~ & | ^	any	3	4	5, 6	6		1
? :	1st		2	2	2	2	2
? :	2nd and 3rd

Under this rule the ++ and -- operators behave the same way as the binary + and - operators.

Other rules place further restrictions on the combination of essential types that may be used within an expression.

Exception

A non-negative integer constant expression of essentially signed type may be used as the right hand operand to a shift operator.

Amplification

The appropriate uses are:

1. For the + operator, one operand shall have essentially character type and the other shall have essentially signed type or essentially unsigned type. The result of the operation has essentially character type.
2. For the - operator, the first operand shall have essentially character type and the second shall have essentially signed type, essentially unsigned type or essentially character type. If both operands have essentially character type then the result has the standard type (usually int in this case) else the result has essentially character type.

Amplification

The following operations are covered by this rule:

1. Assigning as defined in the Glossary;
2. The conversion of the constant expression in a switch statement's case label to the promoted type of the controlling expression.

Exception

1. A non-negative integer constant expression of essentially signed type may be assigned to an object of essentially unsigned type if its value can be represented in that type.
2. The initializer { 0 } may be used to initialize an aggregate or union type.

Amplification

This rule applies to operators that are described in usual arithmetic conversions [C90 Section 6.2.1.5, C99 Section 6.3.1.8]. This includes all the binary operators, excluding the shift, logical &&, logical || and comma operators. In addition, the 2nd and 3rd operands of the ternary operator are covered by this rule.

Note that the increment and decrement operators are not covered by this rule.

Exception

The following are permitted to allow a common form of character manipulation to be used:

1. The binary + and += operators may have one operand with essentially character type and the other operand with an essentially signed or essentially unsigned type;
2. The binary - and -= operators may have a left-hand operand with essentially character type and a right-hand operand with an essentially signed or essentially unsigned type.

Amplification

The casts which should be avoided are shown in the following table, where values are cast (explicitly converted) to the essential type category of the first column.

Essential type category	from
to	Boolean	character	enum	signed	unsigned	floating
Boolean		Avoid	Avoid	Avoid	Avoid	Avoid
character	Avoid					Avoid
enum	Avoid	Avoid	Avoid*	Avoid	Avoid	Avoid
signed	Avoid
unsigned	Avoid
floating	Avoid	Avoid

* Note that an enumerated type may be cast to an enumerated type provided that the cast is to the same essential enumerated type. Such casts are redundant.

Casting from void to any other type is not permitted as it results in undefined behaviour. This is covered by Rule 1.3

Exception

An integer constant expression with the value 0 or 1 of either signedness may be cast to a type which is defined as essentially Boolean. This allows the implementation of non-C99 Boolean models.

Amplification

This rule covers the assigning operations described in Rule 10.3.

Amplification

A pointer to a function shall only be converted into or from a pointer to a function with a compatible type.

Exception

1. A null pointer constant may be converted into a pointer to a function;
2. A pointer to a function may be converted into void;
3. A function type may be implicitly converted into a pointer to that function type.

Note: exception 3 covers the implicit conversions described in C90 Section 6.2.2.1 and C99 Section 6.3.2.1. These conversions commonly occur when:

• A function is called directly, i.e. using a function identifier to denote the function to be called;
• A function is assigned to a function pointer.

Amplification

A pointer to an incomplete type shall not be converted into another type.

A conversion shall not be made into a pointer to incomplete type.

Although a pointer to void is also a pointer to an incomplete type, this rule does not apply to pointers to void as they are covered by Rule-11.5.

Exception

1. A null pointer constant may be converted into a pointer to an incomplete type.
2. A pointer to an incomplete type may be converted into void.

Amplification

This rule applies to the unqualified types that are pointed to by the pointers.

Exception

It is permitted to convert a pointer to object type into a pointer to one of the object types char, signed char or unsigned char. The Standard guarantees that pointers to these types can be used to access the individual bytes of an object.

Amplification

A pointer should not be converted into an integer.

An integer should not be converted into a pointer.

Exception

A null pointer constant that has integer type may be converted into a pointer to object.

Exception

A null pointer constant that has type pointer to void may be converted into pointer to object.

Exception

An integer constant expression with value 0 may be cast into pointer to void.

Amplification

For the purposes of this rule a non-integer arithmetic type means one of:

• essentially Boolean;
• essentially character;
• essentially enum;
• essentially floating.

Amplification

An integer constant expression with the value 0 shall be derived from expansion of the macro NULL if it appears in any of the following contexts:

• As the value being assigned to a pointer;
• As an operand of an == or != operator whose other operand is a pointer;
• As the 2nd operand of a ?: operator whose 3rd operand is a pointer;
• As the 3rd operand of a ?: operator whose 2nd operand is a pointer.

Ignoring whitespace and any surrounding parentheses, any such integer constant expression shall represent the entire expansion of NULL.

Note: a null pointer constant of the form (void *)0 is permitted, whether or not it was expanded from NULL.

Amplification

The following table is used in the definition of this rule.

Description	Operator or Operand	Precedence
Primary	identifier, constant, string literal, ( expression )	16 (high)
Postfix	[] () (function call) . -> ++ (post-increment) -- (post-decrement) (){} (C99: compound literal)	15
Unary	++ (pre-increment) -- (pre-decrement) & * + - ~ ! sizeof defined (preprocessor)	14
Cast	()	13
Multiplicative	* / %	12
Additive	+ -	11
Bitwise shift	<< >>	10
Relational	< > <= >=	9
Equality	== !=	8
Bitwise AND	&	7
Bitwise XOR	^	6
Bitwise OR	|	5
Logical AND	&&	4
Logical OR	||	3
Conditional	?:	2
Assignment	= *= /= %= += -= <<= >>= &= ^= |=	1
Comma	,	0 (low)

The precedences used in this table are chosen to allow a concise description of the rule. They are not necessarily the same as those that might be encountered in other descriptions of operator precedence.

For the purposes of this rule, the precedence of an expression is the precedence of the element (operand or operator) at the root of the parse tree for that expression.

For example: the parse tree for the expression a << b + c can be represented as:

   
        <<
       /  \
      a    +
          / \
         b   c

The element at the root of this parse tree is '<<' so the expression has precedence 10.

The following advice is given:

• The operand of the sizeof operator should be enclosed in parentheses;
• An expression whose precedence is in the range 2 to 12 should have parentheses around any operand that has both:
  • Precedence of less than 13, and
  • Precedence greater than the precedence of the expression.

Amplification

This rule applies to expressions that satisfy the constraints for a constant-expression, whether or not they appear in a context that requires a constant-expression.

If an expression is not evaluated, for example because it appears in the right operand of a logical AND operator whose left operand is always false, then this rule does not apply.

Amplification

Between any two adjacent sequence points or within any full expression:

1. No object shall be modified more than once;
2. No object shall be both modified and read unless any such read of the object's value contributes towards computing the value to be stored into the object;
3. There shall be no more than one modification access with volatile-qualified type;
4. There shall be no more than one read access with volatile-qualified type.

Note: An object might be accessed indirectly, by means of a pointer or a called function, as well as being accessed directly by the expression.

Note: This Amplification is intentionally stricter than the headline of the rule. As a result, expressions such as:

   x = x = 0;

are not permitted by this rule even though the value and the persistent side-effects, provided that x is not volatile, are independent of the order of evaluation or side-effects.

Sequence points are summarized in Annex C of both the C90 and C99 standards. The sequence points in C90 are a subset of those in C99.

Full expressions are defined in Section 6.6 of the C90 standard and Section 6.8 of the C99 standard.

Amplification

A function call is considered to be a side effect for the purposes of this rule.

All sub-expressions of the full expression are treated as if they were evaluated for the purposes of this rule, even if specified as not being evaluated by The Standard.

Amplification

This rule applies even if the expression containing the assignment operator is not evaluated.

Amplification

Any expressions appearing in the operand of a sizeof operator are not normally evaluated. This rule mandates that the evaluation of any such expression shall not contain side-effects, whether or not it is actually evaluated.

A function call is considered to be a side effect for the purposes of this rule.

Exception

An expression of the form sizeof ( V ), where V is an lvalue with a volatile qualified type that is not a variable-length array, is permitted.

Amplification

The three clauses of a for statement are the:

First clause which

• Shall be empty, or
• Shall assign a value to the loop counter, or
• Shall define and initialize the loop counter (C99).

Second clause which

• Shall be an expression that has no persistent side-effects, and
• Shall use the loop counter and optionally loop control flags, and
• Shall not use any other object that is modified in the for loop body.

Third clause which

• Shall be an expression whose only persistent side-effect is to modify the value of the loop counter, and
• Shall not use objects that are modified in the for loop body.

There shall only be one loop counter in a for loop, which shall not be modified in the for loop body.

A loop control flag is defined as a single identifier denoting an object with essentially Boolean type that is used in the Second clause.

The behaviour of a for loop body includes the behaviour of any functions called within that statement.

Exception

All three clauses may be empty, for ( ; ; ), so as to allow for infinite loops.

Amplification

This rule applies to:

• Controlling expressions of if, while, for, do ... while and switch statements;
• The first operand of the ?: operator.

Exception

1. Invariants that are used to create infinite loops are permitted.
2. A do-while loop with an essentially Boolean controlling expression that evaluates to 0 is permitted.

Amplification

The controlling expression of a for-statement is optional. The rule does not require the expression to be present but does require it to have essentially Boolean type if it is present.

Amplification

For the purposes of this rule, a switch-clause that does not consist of a compound statement is treated as if it were a block.

Amplification

A function should have no more than one return statement.

When a return statement is used, it should be the final statement in the compound statement that forms the body of the function.

Amplification

The body of an iteration-statement (while, do ... while or for) or a selection-statement (if, else, switch) shall be a compound-statement.

Exception

An if statement immediately following an else need not be contained within a compound statement.

Amplification

A final else statement shall always be provided whenever an if statement is followed by a sequence of one or more else if constructs. The else statement shall contain at least either one side-effect or a comment.

Amplification

A switch statement shall be considered to be well-formed if it conforms to the subset of C switch statements that is specified by the following syntax rules. If a syntax rule given here has the same name as one defined in The Standard then it replaces the standard version for the scope of the switch statement; otherwise, all syntax rules given in The Standard are unchanged.

   
   switch-statement:
      switch ( switch-expression ) { case-label-clause-list final-default-clause-list }
      switch ( switch-expression ) { initial-default-clause-list case-label-clause-list }

   
   case-label-clause-list:
      case-clause-list
      case-label-clause-list case-clause-list

   
   case-clause-list:
      case-label switch-clause
      case-label case-clause-list

   
   case-label:
      case constant-expression:

   
   final-default-clause-list:
      default: switch-clause
      case-label final-default-clause-list

   
   initial-default-clause-list:
      default: switch-clause
      default: case-clause-list

   
   switch-clause:
      statement-list<sub>opt</sub> break;
      C90: { declaration-list<sub>opt</sub> statement-list<sub>opt</sub> break; }
      C99: { block-item-list<sub>opt</sub> break; }

Except where explicitly permitted by this syntax, the case and default keywords may not appear anywhere within a switch statement body.

Note: some of the restrictions imposed on switch statements by this rule are expounded in the rules referenced in the "See also" section. It is therefore possible for code to violate both this rule and one of the more specific rules.

Note: the term switch label is used within the text of the specific switch statement rules to denote either a case label or a default label.

Amplification

The switch-clause following the default label shall, prior to the terminating break statement, contain either:

• A statement, or
• A comment.

Amplification

None of va_list, va_arg, va_start, va_end and, for C99, va_copy shall be used.

Amplification

If a parameter is declared as an array with a specified size, the corresponding argument in each function call should point into an object that has at least as many elements as the array.

Amplification

Creation of a pointer to one beyond the end of the array is well-defined by The Standard and is permitted by this rule. Dereferencing a pointer to one beyond the end of an array results in undefined behaviour and is forbidden by this rule.

This rule applies to all forms of array indexing:

   integer_expression + pointer_expression
   pointer_expression + integer_expression
   pointer_expression - integer_expression
   pointer_expression += integer_expression
   pointer_expression -= integer_expression
   ++pointer_expression
   pointer_expression++
   --pointer_expression
   pointer_expression--
   pointer_expression [ integer_expression ]
   integer_expression [ pointer_expression ]

Note: a subarray is also an array.

Note: for purposes of pointer arithmetic, The Standard treats an object that is not a member of an array as if it were an array with a single element (C90 Section 6.3.6, C99 Section 6.5.6).

Exception

Subject to Rule-18.2, pointer subtraction between two pointers is allowed.

Amplification

No more than two pointer declarators should be applied consecutively to a type. Any typedef-name appearing in a declaration is treated as if it were replaced by the type that it denotes.

Amplification

The address of an object might be copied by means of:

• Assignment;
• Memory move or copying functions.

Exception

The following are permitted because the behaviour is well-defined:

1. Assignment between two objects that overlap exactly and have compatible types (ignoring their type qualifiers)
2. Copying between objects that overlap partially or completely using The Standard Library function memmove

Amplification

The rule shall be applied to the contents of a file before preprocessing occurs.

Amplification

This rule applies after macro replacement has been performed.

Amplification

This rule applies to all keywords, including those that implement language extensions.

Amplification

If the expansion of any macro parameter produces a token, or sequence of tokens, that form an expression then that expression, in the fully-expanded macro, shall either:

• Be a parenthesized expression itself; or
• Be enclosed in parentheses.

Note: this does not necessarily require that all macro parameters are parenthesised; it is acceptable for parentheses to be provided in macro arguments.

Amplification

This rule does not apply to controlling expressions in preprocessing directives which are not evaluated. Controlling expressions are not evaluated if they are within code that is being excluded and cannot have an effect on whether code is excluded or not.

Amplification

As well as using a #define preprocessor directive, identifiers may effectively be #define'd in other, implementation-defined, ways. For example some implementations support:

• Using a compiler command-line option, such as -D to allow identifiers to be defined prior to translation;
• Using environment variables to achieve the same effect;
• Pre-defined identifiers provided by the compiler.

Amplification

White-space is permitted between the # and preprocessing tokens.

Amplification

This rule applies to the following:

• Identifiers or macro names beginning with an underscore;
• Identifiers in file scope described in Section 7, "Library", of The Standard;
• Macro names described in Section 7, "Library", of The Standard as being defined in a standard header.

This rule also prohibits the use of #define or #undef on the identifier defined as this results in explicitly undefined behaviour.

This rule does not include those identifiers or macro names that are described in the section of the applicable C standard entitled "Future Library Directions."

The Standard states that defining a macro with the same name as:

• A macro defined in a standard header, or
• An identifier with file scope declared in a standard header

is well-defined provided that the header is not included. This rule does not permit such definitions on the grounds that they are likely to cause confusion.

Note: the macro NDEBUG is not defined in a standard header and may therefore be #define'd.

Amplification

See the Amplification for Rule-21.1 for a description of the relevant identifiers and macro names.

Amplification

The identifiers calloc, malloc, realloc and free shall not be used and no macro with one of these names shall be expanded.

Amplification

None of the facilities that are specified as being provided by <setjmp.h> shall be used.

Amplification

None of the facilities that are specified as being provided by <signal.h> shall be used.

Amplification

This rule applies to the functions that are specified as being provided by <stdio.h> and, in C99, their wide-character equivalents specified in Sections 7.24.2 and 7.24.3 of the C99 Standard as being provided by <wchar.h>.

None of these identifiers shall be used and no macro with one of these names shall be expanded.

Amplification

The identifiers atof, atoi, atol and, for C99 only atoll, shall not be used and no macro with one of these names shall be expanded.

Amplification

The identifiers abort, exit, getenv and system shall not be used and no macro with one of these names shall be expanded.

Amplification

The identifiers bsearch and qsort shall not be used and no macro with one of these names shall be expanded.

Amplification

None of the facilities that are specified as being provided by <time.h> shall be used.

In C99, the identifier wcsftime shall not be used and no macro with this name shall be expanded.

Amplification

None of the facilities that are specified as being provided by <tgmath.h> shall be used.

Amplification

The identifiers feclearexcept, fegetexceptflag, feraiseexcept, fesetexceptflag and fetestexcept shall not be used and no macro with one of these names shall be expanded.

The macros FE_INEXACT, FE_DIVBYZERO, FE_UNDERFLOW, FE_OVERFLOW, FE_INVALID and FE_ALL_EXCEPT, along with any implementation-defined floating-point exception macros, shall not be used.

Amplification

The Standard Library functions that allocate resources are malloc, calloc, realloc and fopen.

Amplification

The Standard Library functions that allocate memory are malloc, calloc and realloc.

A block of memory is freed when its address is passed to free and potentially freed when its address is passed to realloc. Once freed, a block of memory is no longer considered to be allocated and therefore cannot subsequently be freed again.

Amplification

This rule applies to files opened with The Standard Library functions. It may also apply to similar features provided by the execution environment.

Amplification

A pointer to a FILE object shall not be dereferenced directly or indirectly (e.g. by a call to memcpy or memcmp).