MISRA C Compliance Suites

SuperTest MISRA C Compliance Suites

The SuperTest MISRA C Compliance Suites are created to verify the conformance of MISRA checking software. The aim of a, so-called, MISRA checker is to check application software for its compliance with the MISRA guidelines. This is an important task, even safety-critical, because the MISRA guidelines aim to reduce the impact of the pitfalls that are inherent to C programming.

But who checks the checker? A mistake in the MISRA checker may overlook a guideline violation and leave one of these pitfalls wide open. The SuperTest MISRA C Compliance Suites verify that a MISRA checker generates the right diagnostics and not too many false positives or false negatives. Solid Sands offers compliance suites for:

  • MISRA C:2004
  • MISRA C:2012
  • MISRA C:2012 Amendment 1

The MISRA C Compliance Suites are offered as a separate package from the SuperTest Compiler Test and Validation Suite.

Suite Organization

The SuperTest MISRA C Complaince Suites are each available in multiple variants with further language version specific sub-variants:

  • A generic variant that is impartial to a specific data-model. By means of Directive 4.6, MISRA C:2012 recommends developers to make a choice of data-model. This means that specific bit-sizes are to be encoded in the type names for all the arithmetic types. The generic variant of a SuperTest MISRA C Complaince suite makes no such choice and uses the standard arithmetic types of the C programming language.
  • A variant that does assume a specific data-model: 8 bit characters, 16 bit shorts, 32 bit integers, 32 bit longs, 64 bit long longs, 32 bit floats, 64 bit doubles and 96 bit long doubles.
  • A variant that does assume another specific data-model: 8 bit characters, 16 bit shorts, 32 bit integers, 64 bit longs, 64 bit long longs, 32 bit floats, 64 bit doubles and 128 bit long doubles.

Solid Sands can also provide additional instances of the MISRA suites that are specific for another data model, if needed.

All variants have a sub-suite specifically for C90. In the MISRA C:2012 and MISRA C:2012 A1 suites, there is also a sub-directory specifically for C99. They contain the tests that are compliant to the respective version of the C standard.

Test Examples

All MISRA suites contain two types of tests: those with a name starting with a ‘t’, and those with a name that starts with an ‘x’. The differences between these types of tests are discussed below.

T-tests

The so-called t-tests are fully conforming with the MISRA guidelines and should not trigger any diagnostics in the MISRA checking software.

This is an example of a t-test:

 /*
  * Test for MISRA-C:2004 Rule 4.2:
  *     Trigraphs shall not be used
  */
 typedef signed int int32_t;
 static int32_t fun (void);
 static int32_t fun (void) {
     char r[50] = "OK: ??? ??.??+??~??^"; /* Compliant */
     return (r[0] != 'O') ? (int32_t)1 : (int32_t)0;
 }

 int32_t main (void) {
     return fun ();
 }

In this test, the string that initializes the variable r contains a number of character sequences that look like trigraph sequences, which the MISRA guidelines do not allow, but are not trigraphs. Hence, this code is compliant with MISRA Rule 4.2. No diagnostic should be given. The code is also constructed so that no other MISRA rules are violated.

 

X-tests

The x-tests contain a violation of one of the MISRA rules. When passed to a MISRA checker, they should trigger a diagnostic for a specific rule.

Here is an example of an x-test that violates Rule 5.4, which requires that tags are unique.

 /*
  * Test for MISRA-C:2004 Rule 5.4:
  *     A tag name shall be a unique identifier
  *
  * Notes on test:
  * Check that the following code violates MISRA Rule 5.4
  */
 typedef unsigned short uint16_t;
 typedef signed int int32_t;
 typedef unsigned int uint32_t;
 int32_t main (void) {
     uint32_t aval;
     {
         enum thetag { x, y, z };
         enum thetag ty = y;
         aval = (ty < x) ? (int32_t)1U : (int32_t)0U;
     }
     {
         struct thetag {    /* Not compliant */
             uint16_t a;
             uint16_t b;
         } str = {3U, 4U};
         aval += str.a;
     }
     return (aval != 3U) ? (int32_t)1 : (int32_t)0;
 }

Note that this x-test is perfectly fine C90 code. C90 allows the reuse of thetag in different scopes. But MISRA does not.

A big effort has been put into making the x-tests as specific as possible, so that they contain only one rule violation, and at the same time keep them concise and understandable. This is not always possible. Sometimes rules partially overlap and an additional diagnostic is triggered.

 

Undecidable Rules

Some of the MISRA rules are what is called undecidable. This means that for complex examples of such code, a MISRA checker may not be able to follow the control and data flow with sufficiently detail to decide if a rule is violated or not. For such rules, there are often ‘trivial’ cases for which a MISRA checker is expected to give a diagnostic. We have included such trivial cases in the suites as well. We have also included more complex cases that are decidable with some effort. The following is an example of a t-test for an undecidable rule, so it should not give a diagnostic:

 /*
  * Test for MISRA-C:2004 Rule 17.3:
  *      >, >=, <, <= shall not be applied to pointer
  *      types except where they point to the same array
  *
  * Notes on test:
  * Check that the code does not violate MISRA Rule 17.3
  */  
 typedef signed int int32_t;

 int32_t main (void) {
     int32_t a[] = {1, 2, 3};
     int32_t *pa = &a[1];
     int32_t r = 9;
 
     if (&a[2] > pa) {   /* Compliant */
         r = 6;
     }
     return r - 6;
 }

To verify that the pointer comparison is compliant, requires that a MISRA checker applies non-trivial data flow analysis to the code. If the MISRA checker cannot do that, it might decide to play it safe and generate a (false positive) warning: an incorrect diagnostic for a (possible) rule violation. The MISRA checker may offer an option to suppress warnings.

The MISRA test suite comes in several flavors. By means of (advisory) Rule 6.3, MISRA forces application developers to choose a data model and express that choice in the primitive types used for arithmetic. This can be seen in the examples above, which use the 32-bit integer type “int32_t”.

The MISRA suites are supplied both in a generic form and in a form that is specific for a data model. The examples above are all for a specific data model. In the generic form, the previous example looks like this:

int main (void) {
    int a[] = {1, 2, 3};
    int *pa = &a[1];
    int r = 9;
    if (&a[2] > pa) {   /* Compliant */
        r = 6;
    }
    return r - 6;
}

In this form, one should tell the MISRA checker that it should ignore Rule 6.3.

Do you want to learn more about the SuperTest MISRA C Compliance Suites? Click the button below to contact us!

Contact us