26-11-2009, 10:18 AM
PC Lint and many other checking tools have adopted the MISRA rules after laying out their warning concepts earlier (PC Lint exists since the middle of the eighties!). Unless a tool has designed/revised its warning system to exactly match MISRA's ideas on what is good and what is not, there will be some areas not properly covered, and other areas covered too restrictively.
Have a look in the 'au-misra2.lnt' file in your distribution, and look for the messages enabled for the various MISRA rules. For instance, for rule 11.1, warning 923 is activated. The rule forbids conversions between function pointers and non-integral types. Warning 923 of Lint warns about conversions between pointers and non-pointers. For observation of only rule 11.1, Lint is too restrictive. But the mapping has been created with the premise that it's better to warn too often than not at all.
Since the Lint configuration file for MISRA is a tool and not the law, if you find discrepancies you want to avoid, create your own version of the options file, or provide deviations in the source code, at your discretion.
And for the record: This is a restriction of all tools claiminng to "support MISRA" I have seen to date. The quality of the MISRA support is dependent on the warning granularity of the original product. And for instance, the concept of 'underlying type' was introduced by MISRA 2004; several tools still have difficulties in this area, because the concept was never in their architectures until MISRA 2004 came out.
Even if it's not much concrete help for your present situation, I hope the explanation helps clarify your options.
BR,
Johan
Have a look in the 'au-misra2.lnt' file in your distribution, and look for the messages enabled for the various MISRA rules. For instance, for rule 11.1, warning 923 is activated. The rule forbids conversions between function pointers and non-integral types. Warning 923 of Lint warns about conversions between pointers and non-pointers. For observation of only rule 11.1, Lint is too restrictive. But the mapping has been created with the premise that it's better to warn too often than not at all.
Since the Lint configuration file for MISRA is a tool and not the law, if you find discrepancies you want to avoid, create your own version of the options file, or provide deviations in the source code, at your discretion.
And for the record: This is a restriction of all tools claiminng to "support MISRA" I have seen to date. The quality of the MISRA support is dependent on the warning granularity of the original product. And for instance, the concept of 'underlying type' was introduced by MISRA 2004; several tools still have difficulties in this area, because the concept was never in their architectures until MISRA 2004 came out.
Even if it's not much concrete help for your present situation, I hope the explanation helps clarify your options.
BR,
Johan
<r>Johan Bezem<br/>
Email: <EMAIL email="[email protected]">[email protected]</EMAIL><br/>
Tel: +49 172 5463210<br/>
Web: <URL url="http://www.bezem.de/">http://www.bezem.de/</URL></r>
Email: <EMAIL email="[email protected]">[email protected]</EMAIL><br/>
Tel: +49 172 5463210<br/>
Web: <URL url="http://www.bezem.de/">http://www.bezem.de/</URL></r>