MISRA.EXPANSION.UNSAFE

Unsafe macro usage.

MISRA-C Rule 20.1 (required): Reserved identifiers, macros and functions in the standard library, shall not be defined, redefined or undefined.

This rule is also covered by MISRA.DEFINE.WRONGNAME.UNDERSCORE, MISRA.DEFINE.WRONGNAME and MISRA.DEFINE.INCL.UNSAFE.

[Undefined 54, 57, 58, 62]

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.5 (required): The error indicator errno shall not be used.

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

[Implementation 46, Koenig 73]

errno is a facility of C, which in theory should be useful, but which in practice is poorly defined by the standard. A non zero value may or may not indicate that a problem has occurred; as a result it shall not be used. Even for those functions for which the behaviour of errno is well defined, it is preferable to check the values of inputs before calling the function rather than rely on using errno to trap errors (see Rule 16.10).

MISRA-C Rule 20.6 (required): The macro ''offsetof'', in library ''<stddef.h>'', shall not be used.

[Undefined 59]

Use of this macro can lead to undefined behaviour when the types of the operands are incompatible or when bit fields are used.

MISRA-C Rule 20.7 (required): The setjmp macro and the longjmp function shall not be used.

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

[Unspecified 14; Undefined 64—67, Koenig 74]

setjmp and longjmp allow the normal function call mechanisms to be bypassed, and shall not be used.

MISRA-C++ Rule 17-0-5 (required): The setjmp macro and the longjmp function shall not be used.

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

Rationale

setjmp and longjmp allow the normal function call mechanisms to be bypassed, and shall not be used, since exception handling provides a better defined mechanism for this.

Example

#include <setjmp.h>

void f2 ( );

jmp_buf buf;

void f1 ( )
{
   if ( !setjmp ( buf ) ) // Non-compliant
   {
      f2 ( );
   }
   else
   {
   }
}
void f2 ( )
{
   longjmp ( buf, 10 ); // Non-compliant
}

MISRA-C++ Rule 18-0-1 (required): The C library shall not be used.

Rationale

Some C++ libraries (e.g. <cstdio>) also have corresponding C versions (e.g. <stdio.h>). This rule requires that the C++ version is used.

MISRA-C++ Rule 18-2-1 (required): The macro offsetof shall not be used.

Rationale

Use of this macro can lead to undefined behaviour when the types of the operands are incompatible, or when bit fields are used.

Example

#include <cstddef>
struct A
{
   int32_t i;
};
void f1 ( )
{
   offsetof ( A, i ); // Non-compliant
}

MISRA-C++ Rule 19-3-1 (required): The error indicator errno shall not be used.

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

Rationale

errno is a facility of C++ which should in theory be useful, but which in practice is poorly defined by ISO/IEC 14882:2003 [1]. A non-zero value may or may not indicate that a problem has occurred; therefore errno shall not be used.

Even for those functions for which the behaviour of errno is well defined, it is preferable to check the values of inputs before calling the function rather than relying on using errno to trap errors.

Example

#include <cstdlib>
#include <cerrno>

void f1 ( const char_t * str )
{
   errno = 0;        // Non-compliant
   int32_t i = atoi ( str );
   if ( 0 != errno ) // Non-compliant
   {
      // handle error case???
   }
}

External guidance

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