31-08-2016, 03:20 PM
Thanks for the replies.
We actually use PC-Lint and refer to the document in the link you sent (@dg1980).
Since Lint provides partial checking of Rule 1.3, what I do is look into the provided options file (au-misra3.lnt) and look at what checks are being done. The list for this rule is extensive.
I then print out Annex J of C99 and number the behaviours. The behaviours that are not covered by Lint or other MISRA guidelines (according to Appendix H of the guidelines) are highlighted and then checked manually. Many of these checks can be performed by searching for a simple term. For example, it's possible to rule out the following undefined behaviour by searching the source code for 'errno':
"A macro definition of errno is suppressed in order to access an actual object, or the
program defines an identifier with the name errno."
Some of the checks aren't as quick and easy. The result is a source code review that is swollen takes a long time to complete.
I think that there are certain types of projects where a deviation to Rule 1.3 is justifiable, in order to forego a manual review (although diagnostics relating to Rule 1.3 should still be dealt with). If, for example, no Standard Library functions are used, only exact-width integers are used and no floating-point numbers are used, then many of these behaviours cannot be present.
There is also some overlap with other rules (e.g. Rule 1.1, as some constructs result in constraint violations and undefined behaviour).
It's worth noting that if Lint is the only static analysis tool used, then any claim of MISRA compliance necessarily involves a manual review, as there are mandatory rules that are either not checked or only partially checked.
We actually use PC-Lint and refer to the document in the link you sent (@dg1980).
Since Lint provides partial checking of Rule 1.3, what I do is look into the provided options file (au-misra3.lnt) and look at what checks are being done. The list for this rule is extensive.
I then print out Annex J of C99 and number the behaviours. The behaviours that are not covered by Lint or other MISRA guidelines (according to Appendix H of the guidelines) are highlighted and then checked manually. Many of these checks can be performed by searching for a simple term. For example, it's possible to rule out the following undefined behaviour by searching the source code for 'errno':
"A macro definition of errno is suppressed in order to access an actual object, or the
program defines an identifier with the name errno."
Some of the checks aren't as quick and easy. The result is a source code review that is swollen takes a long time to complete.
I think that there are certain types of projects where a deviation to Rule 1.3 is justifiable, in order to forego a manual review (although diagnostics relating to Rule 1.3 should still be dealt with). If, for example, no Standard Library functions are used, only exact-width integers are used and no floating-point numbers are used, then many of these behaviours cannot be present.
There is also some overlap with other rules (e.g. Rule 1.1, as some constructs result in constraint violations and undefined behaviour).
It's worth noting that if Lint is the only static analysis tool used, then any claim of MISRA compliance necessarily involves a manual review, as there are mandatory rules that are either not checked or only partially checked.
<t></t>