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

PC-lint Plus Support for AUTOSAR

Gimpel Software has supported the embedded and safety critical software communities since our inception and our tools have supported MISRA and other relevant coding standards for nearly 20 years. The current release of PC-lint Plus builds on this track record by introducing support for the AUTOSAR17 coding guidelines. Nearly 200 guidelines (over 60% of the statically checkable guidelines) are supported in version 1.3 with support for additional guidelines being added in every release.

Many guidelines are supported via dedicated diagnostics to ensure accurate analysis with the specifics associated with the guidelines and their exceptions. Checking for AUTOSAR compliance is easily accomplished by adding a reference to the au-autosar.lnt file (distributed with PC-lint Plus) to your existing configuration. This file enables the messages corresponding to AUTOSAR guidelines and adds text to issued messages specifying the rules(s) associated with each applicable message. The au-autosar.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:

    using int32_t = int;

    namespace Networking {
        enum class MsgType { NORMAL, SYN, ACK, ERROR, OTHER };

        class CommMsg {
            CommMsg(int32_t msg_id = 0); 
            virtual ~CommMsg();
            CommMsg & operator=(const CommMsg& other) {
                _msg_id = other._msg_id;
                _payload = other._payload;
                _mt = other._mt;

            int32_t _msg_id;
            void * _payload;
            MsgType _mt;

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

    note 9418: enum 'Networking::MsgType' does not have an explicitly specified
        underlying type [AUTOSAR Rule A7-2-2]
        enum class MsgType { NORMAL, SYN, ACK, ERROR, OTHER };

    note 9169: constructor 'Networking::CommMsg::CommMsg(int32_t)' can be used for
        implicit conversions from fundamental type 'int32_t' (aka 'int') [AUTOSAR Rule A12-1-4]
            CommMsg(int32_t msg_id = 0);

    warning 1529: assignment operator 'Networking::CommMsg::operator=' should check
        for self-assignment [AUTOSAR Rule A12-8-5]
            CommMsg & operator=(const CommMsg& other) {

Each violation reported includes the location where the violation occurred, a message number and textual description of the underlying issue, and the AUTOSAR Rule that was violated.

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 1529, run PC-lint Plus with the option -help=1529 to have PC-lint Plus display the following:

    The assignment operator does not appear to be checking for assignment of
    the value of a variable to itself (assignment to this). Specifically,
    PC-lint Plus is looking for the first statement of the assignment
    operator be an if statement which compares this to either &argument or
    std::addressof(argument) using either == or !=.
    It is important to check for a self assignment so as to know whether the
    old value should be subject to a delete operation. This is often
    overlooked by a class designer since it is counter-intuitive to assign
    to oneself. But, through the magic of aliasing (pointers, references,
    function arguments) it is possible for an unsuspecting programmer to
    stumble into a disguised self-assignment.
    If you are currently using the following test
        if( arg == *this)
    we recommend you replace this with the more efficient:
        if( &arg == this || arg == *this)

The AUTOSAR guidelines document can be consulted for information about the specified Rule.

In the example above, adding the following test to the beginning of CommMsg::operator= resolves the issue reported by 1529 (and will prevent 1529 from being issued in future runs):

    if (this == &other) { return *this; }

Handling Deviations

Deviations are instances in the source code where a violation of a Rule has been deemed acceptable. When targeting AUTOSAR compliance, formal deviations are necessary for “Required” rules but not “Advisory” rules. In both cases, deviations can be configured in PC-lint Plus using appropriate suppressions. 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 require a comment be added to the source code but most do not.

For example, the violation of AUTOSAR Rule A7-2-2 (which requires enumerations to explicitly specify an underlying type in their definition) is reported by message 9418 which always includes the name of the enumeration in the message. To suppress message 9418 for just this definition, the option -esym(9418, Networking::MsgType) can be added to your project’s configuration file or within a lint comment in the source code containing the offending definition. Commentary can follow this option, perhaps with information related to a formal deviation policy, e.g. -esym(9418, Networking::MsgType) "deviation for A7-2-2, see ABC-123 for approval".

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 AUTOSAR. 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-autosar.lnt file. Individual messages can also be enabled or disabled for library code just as easily using the -elib and +elib options.

See Also