It is generally bad practice to #undef a macro which is defined in the standard library. It is also bad practice to #define a macro name which is a C reserved identifier, a C keyword or the name of any macro, object or function in the standard library. For example, there are some specific reserved words and function names which are known to give rise to undefined behaviour if they are redefined or undefined, including defined, _ _LINE_ _, _ _FILE_ _, _ _DATE_ _, _ _TIME_ _, _ _STDC_ _, errno and assert.

See also Rule 19.6 regarding the use of #undef.

Reserved identifiers are defined by ISO/IEC 9899:1990 [2] Sections 7.1.3 "Reserved identifiers" and 6.8.8 "Predefined macro names". Macros in the standard library are examples of reserved identifiers. Functions in the standard library are examples of reserved identifiers. Any identifier in the standard library is considered a reserved identifier in any context i.e. at any scope or regardless of header files.

The defining, redefining or undefining of the reserved identifiers defined in 7.13 "Future library directions" is advisory.

Rule 20.1 applies regardless of which, if any, header files are included.

MISRA-C Rule 20.8 (required): The signal handling facilities of ''<signal.h>'' shall not be used.

This rule is also covered by MISRA.STDLIB.SIGNAL.

[Undefined 68, 69; Implementation 48—52; Koenig 74]

Signal handling contains implementation-defined and undefined behaviour.

MISRA-C Rule 20.9 (required): The input/output library ''<stdio.h>'' shall not be used in production code.

This rule is also covered by MISRA.STDLIB.STDIO.

[Unspecified 2—5,16—18; Undefined 77—89; Implementation 53—68]

This includes file and I/O functions fgetpos, fopen, ftell, gets, perror, remove, rename and ungetc.

Streams and file I/O have a large number of unspecified, undefined and implementation-defined behaviours associated with them. It is assumed within this document that they will not normally be needed in production code in embedded systems.

If any of the features of stdio.h need to be used in production code, then the issues associated with the feature need to be understood.

MISRA-C Rule 20.12 (required): The time handling functions of library ''<time.h>'' shall not be used.

This rule is also covered by MISRA.STDLIB.TIME.

[Unspecified 22; Undefined 97; Implementation 75, 76]

Includes time, strftime. This library is associated with clock times. Various aspects are implementation dependent or unspecified, such as the formats of times. If any of the facilities of time.h are used then the exact implementation for the compiler being used must be determined and a deviation raised.

MISRA-C++ Rule 18-0-2 (required): The library functions ''atof, atoi'' and ''atol'' from library '<cstdlib>' shall not be used.

This rule is also covered by MISRA.STDLIB.ATOI.

Rationale

These functions have undefined behaviour associated with them when the string cannot be converted.

Example

#include <cstdlib>
int32_t f ( const char_t * numstr )
{
   return atoi ( numstr ); // Non-compliant
}

MISRA-C++ Rule 18-0-4 (required): The time handling functions of library '<ctime>' shall not be used.

This rule is also covered by MISRA.STDLIB.TIME.

Rationale

Various aspects are implementation-defined or unspecified, such as the formats of times.

Example

#include <ctime>

void f ( )
{
   clock ( ); // Non-compliant
}

MISRA-C++ Rule 18-7-1 (required): The signal handling facilities of <csignal> shall not be used.

This rule is also covered by MISRA.STDLIB.SIGNAL.

Rationale

Signal handling contains implementation-defined and undefined behaviour.

Example

#include <csignal>

void my_handler ( int32_t );

void f1 ( )
{
   signal ( 1, my_handler ); // Non-compliant
}

MISRA-C++ Rule 27-0-1 (required): The stream input/output library '<cstdio>' shall not be used.

This rule is also covered by MISRA.STDLIB.STDIO.

Rationale

This includes file and I/O functions fgetpos, fopen, ftell, gets, perror, remove, rename, etc.

Streams and file I/O have a large number of unspecified, undefined and implementation-defined behaviours associated with them.

Example

#include <cstdio>        // Non-compliant

void fn ( )
{
   char_t array [ 10 ];

   gets ( array );       // Can lead to buffer over-run
}

External Guidance

STIG-ID:APP2060.4 The designer will not use unsafe functions documented in the project coding standards