Thursday, December 24, 2015

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.

Wednesday, December 9, 2015

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().