http://www.gimpel.com/Discussion.cfm?ThreadID=5329 brought this to my intention.
You might want to add something like -typemodel=misrac|misracpp|lint which would be set automatically in the author files.
In the example from the forum, the 747 would not be triggered.

For functions which the user has supplied function-wide semantics, I would like to see a flag/mode that allows the provided semantics to essentially "override" the inputs to the function.

For example, if I provide a "_n_p" semantic for a function, I don't want to see a message for possible use of NULL pointer generated within the function; I have already provided a semantic that the parameter is not NULL. Similarly with integral parameters, if I provide a semantic that "1n < 2" and then use that parameter to index into a 2 element array, I don't want to see "possible index out of range" by a billion because the input is considered "unknown".

This is *clearly* predicated on the semantics already being verified as called, as they are through messages 418, 419, 422, 426 and the like.

For functions which the user has supplied function-wide semantics, I would like to see a flag/mode that allows the provided semantics to essentially "override" the inputs to the function.

For example, if I provide a "_n_p" semantic for a function, I don't want to see a message for possible use of NULL pointer generated within the function; I have already provided a semantic that the parameter is not NULL. Similarly with integral parameters, if I provide a semantic that "1n < 2" and then use that parameter to index into a 2 element array, I don't want to see "possible…

Since you're already analyzing the functions, it would seem to be a relatively minor addition to compute a cyclomatic complexity for the function (he said, while signing up someone else to do all the work).

Then, similarly to the "-size" option, the user could be allowed to set a max complexity, above which an info message could be generated.

Most competing tools can generate MISRA compliance reports at the push of a button.
With PC-LINT 9.0L it is a rather tedious procedure, e.g. running with ++efreeze, parsing text output and generating a result.
Not up to date in 2017.

Consider this: a.h contains 10 problems and is included in 10 modules.
That leaves you with 100 lint messages in the log, when in reality there are only 10 problems to fix.
So, having an option that shows messages in header files only the first time it is included would be really cool (and more honest in terms of MISRA violations).

With Lint 9.00L I get a note "960" Violates MISRA 2004Required Rule 14.10, else-branch must have a comment or action.
However, the else branch is not empty. It contains code that is just removed by the preprocessor.
I have seen some similar effects with asm statements where for lint I have done:
#define asm(txt)

With Lint 9.00L I get a note "960" Violates MISRA 2004Required Rule 14.10, else-branch must have a comment or action.
However, the else branch is not empty. It contains code that is just removed by the preprocessor.
I have seen some similar effects with asm statements where for lint I have done:
#define asm(txt)

The C99 standard (Appendix J) identifies almost 200 forms of undefined behavior (UB). For many, many reasons, UB is basically the most egregious form of coding error. It is totally preventable, and the effects can be most devastating.

Even though not all kinds of UB can be detected by a static analysis tool, many are, and other tools do this pretty well.

Piggy-backing onto this -- would also be nice to identify implementation-defined behaviors (e.g. bit position of bit-fields) and unspecified behaviors.

As these are all part of the standard, it doesn't seem too hard to do intellectually, it's just a good amount of work. But work that IMO many users of lint, particularly those working in safety-critical fields such as automotive, energy, medical devices, defense, etc. would love to see.

The C99 standard (Appendix J) identifies almost 200 forms of undefined behavior (UB). For many, many reasons, UB is basically the most egregious form of coding error. It is totally preventable, and the effects can be most devastating.

Even though not all kinds of UB can be detected by a static analysis tool, many are, and other tools do this pretty well.

Piggy-backing onto this -- would also be nice to identify implementation-defined behaviors (e.g. bit position of bit-fields) and unspecified behaviors.

As these are all part of the standard, it doesn't seem too hard to do intellectually, it's just…

According to chapter 5.7 of the manual, PC-LINT determines the language from the file extension.
Therefore, one could assume that in a mixed C/C++ project one would get MISRA C messages in C modules and MISRA C++ messages in C++ modules respectively.
In reality this is not working, even if you use the –indirect option to help PC-LINT:

common.h/* included in all modules to select MISRA standard based on language*/
#ifdef __cplusplus
/*lint –indirect(au-misra-cpp.lnt)*/
#else
/*lint –indirect(au-misra3.lnt)*/
#endif

Depending on the order of the modules processed, you end up with MISRA C messages in C++ modules and vice versa.
PC-LINT should be able to filter and or enable/disable MISRA messages based on the language determined.

According to chapter 5.7 of the manual, PC-LINT determines the language from the file extension.
Therefore, one could assume that in a mixed C/C++ project one would get MISRA C messages in C modules and MISRA C++ messages in C++ modules respectively.
In reality this is not working, even if you use the –indirect option to help PC-LINT:

common.h/* included in all modules to select MISRA standard based on language*/
#ifdef __cplusplus
/*lint –indirect(au-misra-cpp.lnt)*/
#else
/*lint –indirect(au-misra3.lnt)*/
#endif

Depending on the order of the modules processed, you end up with MISRA C messages in C++ modules and vice versa.
PC-LINT…

Although "-vo" and "lint usual arguments ?" are useful, they produce a lot of information, including information that sometimes could be considered 'what was noise' such as temporary error suppressions "-save, -e123, -restore"

It would be great if you could add a feature where I could display all options, suppressions, flags, etc. in effect at a specific point in a source file that have been:
a) changed from the defaults, or
b) changed since the last "-save"
c) changed in this file

Although "-vo" and "lint usual arguments ?" are useful, they produce a lot of information, including information that sometimes could be considered 'what was noise' such as temporary error suppressions "-save, -e123, -restore"

It would be great if you could add a feature where I could display all options, suppressions, flags, etc. in effect at a specific point in a source file that have been:
a) changed from the defaults, or
b) changed since the last "-save"
c) changed in this file

Currently, the xxx.lph precompiled header file is outputted/saved in the same directory as the xxx.h header file, which causes the (often very large) file to be unnecessarily included in source code only backups.

Ideally it would be possible to designate the directory that the .lph precompiled output file is stored in, such as the debug/release build object file directory or a temporary directory.

The documentation sometimes includes sample function names that can be misread as keywords/parameters, for example:
//lint -sem( push, custodial(1))
"push" is often a keyword, for example:
#pragma pack(push, 1)
#pragma warning(push)
the examples in the guide are great, but sample function names that look like they could be parameters is sometimes confusing for me.

Also, if the sample function names were odd-ball and had mixed case, I think it would be a bit clearer, such as FooBar, MyFunc

Greetings,
I've been using Lint for the past 5 years and it's been a very useful tool for me. However, today I discovered an error in my C code that wasn't caught by Lint, and it may be useful if it could be flagged. The error is trying to divide a variable in a structure definition into bitfields where the combined size of the bitfields exceeds the size of the underlying variable.

So, basically, I was trying to fit 14 bits into an 8-bit wide variable.

Regards,
Geoffrey

Greetings,
I've been using Lint for the past 5 years and it's been a very useful tool for me. However, today I discovered an error in my C code that wasn't caught by Lint, and it may be useful if it could be flagged. The error is trying to divide a variable in a structure definition into bitfields where the combined size of the bitfields exceeds the size of the underlying variable.