(610) 584-4261 sales@gimpel.com
Request Evaluation Online Demo
Gimpel Software LLC Logo   Gimpel Software Evaluate Order Support News About

PC-lint Plus Support for MISRA C 2004

PC-lint Plus provides substantial support for the MISRA C 2004 coding guidelines. Checking for MISRA C 2004 compliance is easily accomplished by adding a reference to the au-misra2.lnt file (distributed with PC-lint Plus) to your PC-lint Plus configuration file. This file enables the messages which correspond to MISRA C 2004 guidelines and adds text to the issued messages specifying the rule(s) associated with each applicable message. The au-misra2.lnt file is a plain text, human-readable configuration file using standard PC-lint Plus option syntax that can easily be modified to meet the needs of any individual project.

The Reference Manual that ships with PC-lint Plus includes a support matrix detailing the level of support for each guideline as well as the mechanisms by which each guideline is supported.

Violation Analysis and Presentation

Consider the following example which contains many MISRA C 2004 violations:

    typedef short int16_t;
    typedef int int32_t;
    typedef unsigned short uint16_t;

    int32_t calc(uint16_t id_1, uint16_t id_2, int16_t *idl, uint16_t idl_size);
    int32_t calc(uint16_t id_1, uint16_t id_2, int16_t *idl, uint16_t idl_size) {
        if (idl_size && id_1 < idl_size && id_2 < idl_size)
            return idl[id_1] * idl[id_2] + idl[id_1];
        return 0;
    }

When analyzing this example with PC-lint Plus, the reported MISRA C 2004 violations include (among others):

    904: return statement before end of function 'calc' [MISRA 2004 Rule 14.7, required]
            return idl[id_1] * idl[id_2] + idl[id_1];
            ^

    9012: body should be a compound statement [MISRA 2004 Rule 14.8, required],
        [MISRA 2004 Rule 14.9, required]
            return idl[id_1] * idl[id_2] + idl[id_1];
            ^

    9050: dependence placed on operator precedence (operators '&&' and '<') [MISRA
        2004 Rule 12.1, advisory]
        if (idl_size && id_1 < idl_size && id_2 < idl_size)
                                        ^  ~~~~

    9240: right side of logical operator '&&' is not a primary expression [MISRA
        2004 Rule 12.5, required]
        if (idl_size && id_1 < idl_size && id_2 < idl_size)
                                        ^  ~~~~~~~~~~~~~~~

    9232: expected an effectively boolean argument for operator && [MISRA 2004 Rule
        12.6, advisory]
        if (idl_size && id_1 < idl_size && id_2 < idl_size)
            ~~~~~~~~ ^

    9226: integral expression of underlying type 'int16_t' (aka 'short') cannot be
        implicitly converted to type 'int32_t' (aka 'int') because it is a return
        expression [MISRA 2004 Rule 10.1, required]
            return idl[id_1] * idl[id_2] + idl[id_1];
            ^      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    9050: dependence placed on operator precedence (operators '+' and '*') [MISRA
        2004 Rule 12.1, advisory]
            return idl[id_1] * idl[id_2] + idl[id_1];
                             ~           ^

    9264: array subscript applied to variable 'idl' declared with non-array type
        'int16_t *' (aka 'short *') [MISRA 2004 Rule 17.4, required]
            return idl[id_1] * idl[id_2] + idl[id_1];
                   ^~~

    818: parameter 'idl' of function 'calc(uint16_t, uint16_t, int16_t *, uint16_t)'
        could be pointer to const [MISRA 2004 Rule 16.7, advisory]
    int32_t calc(uint16_t id_1, uint16_t id_2, int16_t *idl, uint16_t idl_size) {

Each violation reported includes the location where the violation occurred, a message number and textual description of the underlying issue, and the MISRA C 2004 Rule that was violated. For example, in the message:

    9012: body should be a compound statement [MISRA 2004 Rule 14.8, required],
        [MISRA 2004 Rule 14.9, required]
            return idl[id_1] * idl[id_2] + idl[id_1];
            ^

9012 is the PC-lint Plus message number and the text of this message is “body should be a compound statement”. The MISRA Rules violated are included in square brackets at the end of the message text. The subsequent two lines show the context and position associated with the message.

Resolving Violations

The PC-lint Plus Reference Manual contains descriptions of each message and often provides additional guidance that can be used to correct the issue. This information can also be displayed on the command line. For example, to display the description of message 818, run PC-lint Plus with the option -help=818 to have PC-lint Plus display the following:

    As an example:

        int f( int *p ) { return *p; }

    can be redeclared as:

        int f( const int *p ) { return *p; }

    Declaring a parameter a pointer to const offers advantages that a mere
    pointer does not. In particular, you can pass to such a parameter the
    address of a const data item. In addition it can offer better
    documentation.
    Other situations in which a const can be added to a declaration are
    covered in messages 952, 953, 954 and 1764.

The MISRA C 2004 guidelines document can be consulted for information about the specified Rule.

One way to rewrite the calc function above to address the reported violations is:

    int32_t calc2(uint16_t id_1, uint16_t id_2, const int16_t id_list[], uint16_t idl_size);
    int32_t calc2(uint16_t id_1, uint16_t id_2, const int16_t id_list[], uint16_t idl_size) {
        int32_t result = 0;
        if ((idl_size > 0U) && (id_1 < idl_size) && (id_2 < idl_size)) {
            result = ((int32_t)id_list[id_1] * id_list[id_2]) + id_list[id_1];
        }
        return result;
    }

Handling Deviations

Deviations are instances in the source code where a violation of a Rule has been reviewed and deemed acceptable. The MISRA C 2004 document contains advisory and required rules. Deviations from required rules generally involve a formal approval process whereas deviations from advisory rules may not. While the details of the deviation process will vary from project to project, deviations can be configured in PC-lint Plus using a very flexible suppression mechanism. Most messages can be suppressed in a variety of ways such as within a file, function, or statement, when referring to a particular symbol or type, or on a particular line. Some types of suppressions are expressed in the form of a special comment in your source code, but most are not.

For example, MISRA 2004 Rule 16.7 (reported above by message 818) is an advisory rule that recommends pointer parameters be declared as pointer to const when possible. This message could be suppressed for the function calc using the option -efunc(818, calc) which can be placed either in the project configuration file or in your source code as a special comment. The other messages from within this function could be suppressed in the same manner. Commentary can follow a suppression option which may include a rationale or formal deviation information.

Library Code

PC-lint Plus distinguishes between library code (which by default includes foreign and system headers but can be customized to include any subset of headers and modules) and project code. By default, PC-lint Plus will check both library code and project code for compliance with MISRA C 2004. It is often desired to limit checking to project code and this is easily accomplished by resetting the library warning level using the options -wlib=4 -wlib=1 after referencing the au-misra2.lnt file. Individual messages can also be enabled or disabled for library code just as easily using the -elib and +elib options.

See Also