Several comments are provided for suppressing messages. In general, it is usually better to use specific flags to suppress a particular error permanently, but the general error suppression flags may be more convenient for quickly suppressing messages for code that will be corrected or documented later.
No errors will be reported in code regions between /*@[email protected]*/ and /*@[email protected]*/. These comments can be used to easily suppress an unlimited number of messages, but are dangerous since if real errors are introduced in the ignore ... end region they will not be reported. The ignore and end comments must be matched - a warning is printed if the file ends in an ignore region or if ignore is used inside ignore region.i
No errors will be reported from an /*@[email protected]*/ comment to the end of the line.i<n>
No errors will be reported from an /*@i<n>@*/ (e.g., /*@[email protected]*/) comment to the end of the line. If there are not exactly n errors suppressed from the comment point to the end of the line, LCLint will report an error. This is more robust than i or ignore since a message is generated if the expected number errors is not present. Since errors are not necessarily detected until after this file is processed (for example, and unused variable error), suppress count errors are reported after all files have been processed. The -supcounts flag may be used to suppress these errors. This is useful when a system if being rechecked with different flag settings.t
Like i and i<n>, except controlled by +tmpcomments flag. These can be used to temporarily suppress certain errors. Then, -tmpcomments can be set to find them again.
Control comments may also be used to override type access
settings. The syntax /*@access <type>,+@*/ allows the following code to
access the representation of <type>. Similarly,
/*@noaccess <type>,+@*/ restricts access
to the representation of <type>. The type in a noaccess
comment must have been declared as an abstract type. Type access
applies from the point of the comment to the end of the file or the next
access control comment for this type.
The /*@[email protected]*/indicates that the next macro definition is
not intended to be a function, and should be expanded in line instead of
checked as a macro function definition.
Traditional Lint Comments
Traditional Lint Comments
Some of the control comments supported by most standard UNIX lints are supported by LCLint so legacy systems can be checked more easily. These comments are not lexically consistent with LCLint comments, and their meanings are less precise (and may vary between different lint programs), so we recommend that LCLint comments are used instead except for checking legacy systems already containing standard lint comments.
These standard lint comments supported by LCLint:
/*FALLTHROUGH*/ (alternate misspelling, /*FALLTHRU*/)
Prevents errors for fall-through cases. Same meaning as /*@[email protected]*/./*NOTREACHED*/
Prevents errors about unreachable code (until the end of the function). Same meaning as /*@[email protected]*/./*PRINTFLIKE*/
Arguments similar to the printf library function (there didn't seem to be much of a consensus among standard lints as to exactly what this means). LCLint supports:/*ARGSUSED*/
/*@[email protected]*/Function takes zero or more arguments of any type, an unmodified char * format string argument and zero of more arguments of type and number dictated by the format string. Format codes are interpreted identically to the printf standard library function. May return a result of any type. (LCLint interprets /*PRINTFLIKE*/ as /*@[email protected]*/.)/*@[email protected]*/
Like printflike, except format codes are interpreted as in the scanf library function.
Turns off unused parameter messages for this function. The control comment, /*@[email protected]*/ can be used to the same effect, or /*@[email protected]*/ can be used in individual parameter declarations.
LCLint will ignore standard lint comments if -lintcomments is used. If +warnlintcomments is used, LCLint generates a message for standard lint comments and suggest replacements,
Next: Appendix F. Libraries