+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21)
+---- Forum: 8.1 A standard C environment (https://forum.misra.org.uk/forumdisplay.php?fid=156)
+---- Thread: Rule 1.3 - What do people do to check this rule? (/showthread.php?tid=1269)
Rule 1.3 - What do people do to check this rule? - delta_controls - 23-08-2016
Hi,
Of the 191 undefined behaviours listed in C99, there are 61 that have no associated MISRA guideline. Checking all of these is particularly labourious, especially as the list in Annex J is not numbered.
How do people go about checking conformity with this catch-all rule?
Does anyone globally deviate from this rule, since the most important and most likely behaviours are addressed by other guidelines and checking the others is not practical?
Thanks.
Re: Rule 1.3 - What do people do to check this rule? - dg1980 - 26-08-2016
Just rely on whatever static code analysis tool you are using.
If they claim to fully support MISRA C 2012 they have to check for all Rule 1.3 violations.
Publicly available example (look for Rule 1.3 support): http://gimpel.com/html/misra3.pdf
Re: Rule 1.3 - What do people do to check this rule? - swestin - 26-08-2016
dg1980 Wrote:Just rely on whatever static code analysis tool you are using.
If they claim to fully support MISRA C 2012 they have to check for all Rule 1.3 violations.
Publicly available example (look for Rule 1.3 support): http://gimpel.com/html/misra3.pdf
I'm afraid this isn't very good advice.
To begin with, no software can deliver MISRA compliance; it's just one tool to help along the way. There's an entire list of procedures and (non-code) standards that must be followed.
Second, there are MISRA code guidelines that are impossible (or practically impossible) to check automatically. The guidelines flag certain rules and directives as being in this category.
Finally, no software (including static analysis tools) is perfect. Some things may not be completely implemented, or not (yet) implemented at all. And, occasionally, there will be bugs.
So no tool can substitute for a complete understanding of the guidelines; that's what this forum is for.
-Stephen H. Westin
Re: Rule 1.3 - What do people do to check this rule? - dg1980 - 30-08-2016
swestin Wrote:Fair enough, how do you check for rule 1.3 violations then?dg1980 Wrote:Just rely on whatever static code analysis tool you are using.
If they claim to fully support MISRA C 2012 they have to check for all Rule 1.3 violations.
Publicly available example (look for Rule 1.3 support): http://gimpel.com/html/misra3.pdf
I'm afraid this isn't very good advice.
To begin with, no software can deliver MISRA compliance; it's just one tool to help along the way. There's an entire list of procedures and (non-code) standards that must be followed.
Second, there are MISRA code guidelines that are impossible (or practically impossible) to check automatically. The guidelines flag certain rules and directives as being in this category.
Finally, no software (including static analysis tools) is perfect. Some things may not be completely implemented, or not (yet) implemented at all. And, occasionally, there will be bugs.
So no tool can substitute for a complete understanding of the guidelines; that's what this forum is for.
-Stephen H. Westin
Re: Rule 1.3 - What do people do to check this rule? - delta_controls - 31-08-2016
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.
Re: Rule 1.3 - What do people do to check this rule? - Andrew Banks - 02-09-2016
Appendix H.1 lists the Undefined Behaviours
Of the 61 you mention, 46 are Decidable and are of the form "X is undefined" - we decided that 46 rules of the form "Don't use undefined behaviour X" was unnecessary duplication of the generic "Don't use undefined behaviour". A tool that detects the UB will detect them under Rule 1.3 even where other Rules are not specified.
Of the remaining 19 undecidable behaviours, nine are partially addressed by other MISRA C rules... tools may also detect these under Rule 1.3
If, however, you are not using a tool, then a manual code review will need to detect the UB under Rule 1.3, whether there are specific additional MISRA C rules or not!
Re: Rule 1.3 - What do people do to check this rule? - delta_controls - 02-09-2016
Thanks for the reply, Andrew.
Even when only considering Decidable behaviours, it's unlikely that full checking will be claimed by a tool vendor. I have looked at the compliance matrices for PC-Lint, C-STAT and LDRA.
I understand that you had to strike a balance between the number of rules and ease of checking conformity, although an extra 46 rules wouldn't have been necessary, as rules can preclude more than one behaviour (e.g. Rule 21.6), although that comes at the cost of increased restriction.
How would you go about checking Rule 1.3? Surely there's no way of avoiding an extensive manual review (involving a heavily marked-up printout of Annex J of the standard, cross-referenced with Appendix H of the guidelines) whatever tools are used.
Re: Rule 1.3 - What do people do to check this rule? - Andrew Banks - 06-09-2016
delta_controls Wrote:How would you go about checking Rule 1.3? Surely there's no way of avoiding an extensive manual review (involving a heavily marked-up printout of Annex J of the standard, cross-referenced with Appendix H of the guidelines) whatever tools are used.
My personal approach is, in accordance with the Compliance guidance, to base coverage on the tool I'm using... this doesn't necessarily require manual checks, unless the tool's coverage is incomplete.
There is a MISRA C Working Group meeting coming up at the end of September, and I would anticipate the team will put together an "official" response :-)
Re: Rule 1.3 - What do people do to check this rule? - Steve Montgomery - 06-09-2016
Andrew Banks Wrote:My personal approach is, in accordance with the Compliance guidance, to base coverage on the tool I'm using... this doesn't necessarily require manual checks, unless the tool's coverage is incomplete.That sounds fine but I think the point being made by the previous poster is that in practice no tool does provide complete coverage because:
- some behaviours are undecidable;
- most (all?) tools don't implement checks for every decidable behaviour.
I'd agree with that view.
Re: Rule 1.3 - What do people do to check this rule? - misra-c - 23-09-2016
It is accepted that complete checking of rule 1.3 is difficult.
Adherence to rule 1.3 will involve a mixture of checking via tools and a manual process.
Re: Rule 1.3 - What do people do to check this rule? - bycho - 25-10-2016
How about unspecified behaviors?
there are 50 unspecified behaviors in C99, and there is no 'decidable' field in Appendix H, MISRA C:2012.
In Appendix H, some 'Id' are written with 'Guidelines' but 17 Ids are not. i mean no entry in Guidelines field.
are the 17 unspecified behaviors avoided by rule 1.3? or not?
Re: Rule 1.3 - What do people do to check this rule? - bycho - 26-10-2016
Andrew Banks Wrote:Appendix H.1 lists the Undefined Behaviours
Of the 61 you mention, 46 are Decidable and are of the form "X is undefined" - we decided that 46 rules of the form "Don't use undefined behaviour X" was unnecessary duplication of the generic "Don't use undefined behaviour". A tool that detects the UB will detect them under Rule 1.3 even where other Rules are not specified.
Of the remaining 19 undecidable behaviours, nine are partially addressed by other MISRA C rules... tools may also detect these under Rule 1.3
If, however, you are not using a tool, then a manual code review will need to detect the UB under Rule 1.3, whether there are specific additional MISRA C rules or not!
How about unspecified behaviors?
there are 50 unspecified behaviors in C99, and there is no 'decidable' field in Appendix H, MISRA C:2012.
In Appendix H, some 'Id' are written with 'Guidelines' but 17 Ids are not. i mean no entry in Guidelines field.
are the 17 unspecified behaviors avoided by rule 1.3? or not?
Re: Rule 1.3 - What do people do to check this rule? - misra-c - 09-12-2016
7 of the 17 unspecified behaviours mentioned above are marked as "No" in the "Critical" column and are not covered by rule 1.3 as reliance on that behaviour is unlikely to lead to unexpected program operation. The remaining 10 are covered by rule 1.3.
Re: Rule 1.3 - What do people do to check this rule? - xiangke - 09-06-2017
In deed, No tool can provide complete coverage for Rule 1.3. Need the manual review based on coverage of the tool.
does It mean In the ideal case, Still have 19 undecidable behaviours need the manual review?
At the same time, I think it is difficult to coverage the 191 undefined behaviours listed in C99 for Tool suppliers.
Anybody can tell me which tool have the highest coverage for rule 1.3?