PC-Lint: using -estring to suppress MISRA-C warnings in the global wrap-up

Neither the PC-Lint manual nor the Gimpel forum - at least at the time of writing - gives a good recommendation how to suppress MISRA-C warnings in the global wrap-up. This issue pertains for example to the message "Note 960: Violates MISRA 2004 Required Rule 8.9, undefined symbol", which is followed by the name of the undefined symbol. You might have defined this symbol in Assembler, therefore a suppression of this message for this specific symbol is adequate. However:

• All suppressions that pertain to a specific location in the source code are useless, as this message is raised during global wrap-up, where none of these suppressions apply.
• -estring(960, "symbol name") is not specific enough: it suppresses most MISRA-C warning about that symbol, not only the violation of rule 8.9. That's only because most MISRA-C warning have message code 960 or 961. Otherwise this is just the right option to suppress message in the global wrap-up.
• -esym(960, 8.9) disables rules 8.9 for ALL symbols.
• -estring(960, "undefined symbol*symbol name") doesn't work either: it seems like the whole message text is not matched against the expression, only all parts of the message.

Only through some experimentation I finally found the solution: -estring(960, "undefined symbol", "symbol name") Opposite to other options like -esym, the arguments of the -estring option seem to be AND-ed for the match, not OR-ed. Therefore the above -estring option suppresses the MISRA-C warning about undefined symbols just for "symbol name" and nothing else.

PC-Lint: Beware of +libclass default

After using PC-Lint for several years in lots of projects, this one got me nevertheless today. Again.

It started as it had started in various projects before: a developer asking why this earns a warning in that file, but not in some header file. I checked with -vf and sure, the quiet header showed up as a library header. I searched the configuration for any +libdir directive or similiar when the familiarity of this problem struck me like thunder. So here this old but still current article goes:

Say you are using some libraries in your project and have disabled warnings from the headers of the libraries using the -wlib, -elib, or -elibsym options. Some of the platform configuration files created by Gimpel have a lot of -elib options, for example the ones for MS Windows.

To specify which header files are library header files, you use the +libclass, +libdir, +libh, and -library options.

Now here is the catch: the default setting for the +libclass option might classify most of your own header files as library headers and thus apply the relaxed rules for library code to your own code. If warnings appear or vanish when you shift code from one header to another without any apparent reason, it might got you too.

You can easily check if there is a problem with the classification of library headers using the -vf option: PC-Lint outputs for every header file whether it thinks it's a library header or not. You might be in for a surprise!

The default setting for +libclass is (foreign,angle), which means that all headers found via include path and all headers included with angles instead of quotes are library header files (if the -libh and -libdir options don't say otherwise).

This default setting is unfortunate, because I have seen a lot of projects where header files were put into separate directories named "inc" or "public" or something similar and were found via include path. If this holds for your project too, you'll want to change the configuration to +libclass(angle) or +libclass().

PC-Lint: -e??? and -elib(???) have not the effect you might expect

Sometimes I see -elib(???) in my clients' PC-Lint configuration. The intention is to suppress all but syntax errors from library headers. This doesn't work for two reasons. The first one: most syntax errors have a two digit error code, but not all. The reserved range for syntax errors is 1 - 199. This is documented in the PC-Lint manual.

The second reason really took me by surprise as I found out that -elib(???) also suppresses error code 10. I tested this with PC-Lint 9.00k and also the current beta version 9.00k2 and also with -e???. I was informed by the Gimpel support that for historical reasons, a pattern consisting entirely of question marks is treated as a star (*). This is something we recently reviewed and intend to change in the near future as the current behavior is not documented and, as you demonstrate, not intuitive.

So -e??? and -elib(???) have the same effect as -e* and -elib(*) but won't give you the very deserved warning 686: Option '-e*' is suspicious because of 'the likelihood of causing meaningless output'; receiving a syntax error inside a library file most likely means something is wrong with your Lint confinguration. This warning also explains why you should never suppress syntax errors even from library headers. Except for the very rare causes where library headers raise syntax error even with a perfect PC-Lint configuration. You can find a few examples in the co-... files supplied by Gimpel. And then you should only suppress that single syntax error, not all.

Instead of -elib(???) you should use -wlib(1). This actually suppresses all library messages except syntactic errors.

PC-Lint might include wrong system header files

PC-Lint uses by default the environment variable INCLUDE to find system header files. This environment variable might not be set suitably, especially if you have multiple toolchains installed.

In my case I ended up with PC-Lint including Visual Studio header files when checking a Renesas HEW compiled code base. The worst: I got plausible results, so I found it out only accidentally when I switched on the -vf option.

Running PC-Lint with the -vf option from time to time is a good idea anyway to check which files are considered library headers or library modules, which files are actually processed and - which headers are included.

To fix the behavior of PC-Lint I suggest: -incvar(PLEASE_IGNORE_INCLUDE) This tells PC-Lint to use the environment variable PLEASE_IGNORE_INCLUDE instead of INCLUDE. I found no way to just tell PC-Lint not to use any environment variable, just how to change the name of the used environment variable.

PC-Lint: Interrupt Service Routines

PC-Lint regularly warns about Interrupt Service Routines (ISR) not being used. The simplest remedy is just an esym for every ISR: /*lint -esym(528,Interrupt_SCI0_ERI0) */ #pragma interrupt Interrupt_SCI0_ERI0(vect=VECT_SCI0_ERI0) static void Interrupt_SCI0_ERI0(void) { ... } But see how WET this code is? First you tell PC-Lint it's an ISR. Then you tell the toolchain it's an ISR. Then you write the function head, which - surprise! - has the signature of an ISR. We can do better than that: /* Define this once */ #ifdef _lint /*lint -e(961) Suppress MISRA warning for function-like macro */ #define INTERRUPT(VECT,HANDLER) \ /*lint -esym(528,HANDLER) Suppress warning for unused function */ \ static void HANDLER(void) #else #define DO_PRAGMA(X) _Pragma(#X) #define INTERRUPT(VECT,HANDLER) \ DO_PRAGMA(interrupt HANDLER(vect=VECT)) \ static void HANDLER(void) #endif /* And define all your ISR like this: */ INTERRUPT(VECT_SCI0_ERI0,Interrupt_SCI0_ERI0) { ... } More examples for different pragmas expected by other toolchains to follow.

PC-Lint: enum for constants

When using enum for constants, you should leave the enum anonymous like this:

enum { C = 123 };

Otherwise you'll get warnings like 641 when assigning from enum to integer or comparing enum and integer. This would trigger the warnings:

enum Tag { C = 123 };

You still might experience warnings because Lint assumes enums to be signed, so assigment to an unsigned integer raises a Lint warning. Consider to use #define or const for defining constants instead. Then you can clearly indicate the type of the constant.

PC-Lint: Read the message documentation carefully

Most messages are parametrized with a string, type, or symbol. Depending on the type of the parameter, the message can be suppressed with either -estring, -etype, or -esym. The message documentation (the endless list at the end of the user manual) exactly documents the type of the parameters of each message. Don't rely on common sense, the name of a type or function might very will be displayed in a string parameter. Caveat: I experienced once that the documentation is wrong in respect to the parameter type, but otherwise I found the documentation to be helpful.

PC-Lint

Creating a PC-Lint configuration is easy: start up the configuration wizard, select the target platform of your code and it creates a configuration for you. Congratulations, 0.01% of the work of configuring PC-Lint is done. Where to turn for help when problems with PC-Lint arise:

• discussion forum at Gimpel's website
• the user manual
• this blog (as soon as I posted a little more)