A Note about the Although there is a
-efileoption, it doesn't work to suppress messages within a particular file but rather messages that are about a particular file. For example, Error 7 -
"Unable to open include file 'FileName'"includes the name of the file in its message,
-efilecould be used to suppress this message based on the filename inside but cannot be used to suppress messages that do not include the parameterized filename as part of the message (and most do not).
Selective LintingIf you wish to suppress all messages for a particular file, the most obvious solution is to exclude it from the list of files being linted. The downside with this approach is that you lose the benefits of multi-module linting for the file(s) in question as well as missing out on any potentially serious errors within the file. This "selective linting" method is not recommended for these reasons.
Options for individual filesA better approach is to use the
-w#option to change the warning level for just the file in question. FlexeLint processes options in the order in which they appear so if you ran lint as:
flint file1.c file2.c -w1 file3.c
-w1option would only be in effect for file3.c A similar approach can be used for individual message suppression:
flint file1.c file2.c -e438 -e529 file3.c
It usually makes sense to create a project file that contains the names of the modules to lint instead of having to specify them on the command lint each time. An equivalent project.lnt file would look like:
file1.c file2.c -e438 -e529 file3.cYou can then run lint like so:
There is subtle problem with this approach. By default, the
-eoptions will remain in effect for all future files linted. If you later add files to the end of the project list, the suppressions will remain in effect, perhaps inadvertantly, for those files as well. You may think that adding
+e438 +e529after file3.c would address the issue:
file1.c file2.c -e438 -e529 file3.c +e438 +e529 file4.c ...but the problem with this approach is that the
+e/-eoptions work as boolean flags and as such, messages 438 and 529 will be enabled for future files regardless of whether they were originally enabled or not. The proper way to handle this is to use the
file1.c file2.c -save -e438 -e529 file3.c -restore file4.c ...which will only enable the messages if they were enabled when the
-saveoption was encountered. The same approach can be used with
Using -efunc and Another strategy is to use the
-esymoptions. This has the benefit of limiting the effect of the suppressions to a smaller area which is a less blunt approach.
-efuncoption can suppress messages within a specific function.
-esymoption can suppress messages for specific symbols as well as several other parameterizations when using the
For example, many MISRA C messages are grouped together under Note 960 but you may want to only suppress a small number of MISRA rules for a given file. The way to do this is with
-esym(960, <rule-num>), for example:
file1.c file2.c -esym(960, 10.1) file3.c +esym(960, 10.1) file4.c ...will have the effect of suppressing MISRA rule 10.1 for file3.c. Since
-save/-restoredo not work with the esym options we can't use them here. Instead we take advantage of the fact that identical esym options with opposite signs cancel each other out so despite previous and future esym options, the suppression will be in effect for file.3 without affecting other files.
If you have a large number of functions or symbols in the file that you wish to suppress message for though, this can be tedious. Additionally, if you suppress messages for names that are used in other files, you will want to make sure to provide equivalent
+esymoptions as descibed above to prevent the suppressions from spilling into other files. Of course, if you are trying to suppress messages that aren't parameterized in a way that
-efunc/-esymcan match then this approach won't work.