Do not convert pointer to pointer

A cast should not be performed between a pointer to object type and a different pointer to object type (misra2004_11_4_DoNotConvertPointerToPointer.rule)


Description:

"A cast should not be performed between a pointer to object type and a different pointer to object type. Conversions of this type may be invalid if the new pointer type requires a stricter alignment."

Note: This rule skips casting of void type.

Benefits:

Prevents incorrect pointer alignment.

Example:

void foo( ) {
   int* pi;
   char* i;

   i = (char*) pi; // Violation
   i = (char*) &i; // Violation
}

Repair:

Do not convert pointer to different pointer.

References:
MISRA-C:2004 Guidelines for the use of the C language in critical systems
Chapter 6, Section 11

Author
ParaSoft


Tags: cast, pointer, void, pointer alignment, MISRA, critical systems

Do not mix bit-fields

Do not mix bit-fields other data within the same structure (misra2004_3_5_BitFieldStructuresWithoutOtherData.rule)


Description

It is recommended that structures should be declared specifically to hold the sets of bit fields, and do not include any other data within the same structure.

Benefits:

Rule prevents from the potential pitfalls and areas of implementation-defined (i.e.non-portable) behaviour.

Example:

struct message {  /* Violation */
   signed int little: 4;
   unsigned int x_set: 1;

   int size;
};

Repair:

struct message {  /* OK */
   signed int little: 4;
   unsigned int x_set: 1;
};

References:

MISRA-C:2004 Guidelines for the use of the C language in critical systems

Chapter 6, Section 3

Author
ParaSoft

error information shall be tested

Violations:
misra2004-16_10: If a function returns error information, then that error information shall be tested

Description:

"A function (whether it is part of the standard library, a third party library or a user defined function) may provide some means of indicating the occurrence of an error. This may be via an error flag, some special return value or some other means. Whenever such a mechanism is provided by a function the calling program shall check for the indication of an error as soon as the function returns.

However, note that the checking of input values to functions is considered a more robust means of error prevention than trying to detect errors after the function has completed (see Rule 20.3). Note also that the use of errno (to return error information from functions) is clumsy and should be used with care (see Rule 20.5)."

Note:
Rules checks usage of function calls which returns int value and reports violation when this value is not assigned or checked.

Benefits:
Rule helps writing safety code.

Example:

int SomeFunctionReturningError( );

void foo( )  {
   SomeFunctionReturningError( );  // Violation
}

Repair:

int SomeFunctionReturningError( );

int foo( )  {

   int x;
   x = SomeFunctionReturningError( );        // OK
   if (SomeFunctionReturningError( ));       // OK

   switch (SomeFunctionReturningError( )) {  // OK

   }

   return SomeFunctionReturningError( );     // OK
}

References:
MISRA-C:2004 Guidelines for the use of the C language in critical systems

Chapter 6, Section 16

Author
ParaSoft