Questions about Rule 2.1 - Printable Version +- 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.2 Unused code (https://forum.misra.org.uk/forumdisplay.php?fid=157) +---- Thread: Questions about Rule 2.1 (/showthread.php?tid=1045) |
Questions about Rule 2.1 - tsukukazu - 01-04-2014 In rule 2.1 sample code, default: { /* * This default will only be ...... * holds a value that is not ...... */ } The comments here,there are not written neither compliant nor non-compliant. But I have understood to be compliant from the comment. Is it correct? Best Regards. Re: Questions about Rule 2.1 - misra-c - 11-04-2014 The default statement in the example of rule 2.1 may or may not be reachable depending on other code. For instance: 1. If the value of the "enum light" argument is always one of the enumeration's constants, then the default statement is unreachable and the line is not compliant with this rule. 2. If the value of the "enum light" argument can have a value less than 0 or greater than 3, then the default statement can be reached and the line is compliant with this rule. For this reason, Rule 2.1 is marked as "Undecidable", which means that it is not possible to construct a general algorithm that gives a "compliant" / "not compliant" answer for every possible program that may use the "next_light" function. For a particular instance of a program, an analysis tool may be able to determine whether the statement is reachable or not and give a message if appropriate. However, there will be cases where analysis tools can not determine the outcome. Section 6.5 of the MISRA C:2012 guidelines discuss the decidability of rules and how static analysers may differ in the reporting of undecidable rules. Re:Re: Questions about Rule 2.1 - KumikoItoh - 27-10-2014 Dear Misra-c I have an another question. I understand your answer is that the default line in case 1 is not compliant with Rule2.1. But if we delete this default line, it is not compliant with Rule16.4. So how shall we write the compliant code in this case 1 ? Best Regards. Re: Questions about Rule 2.1 - misra-c - 14-11-2014 Thank you for your query. We will reply after our next working group meeting which is on the 3rd December. Re: Questions about Rule 2.1 - misra-c - 05-12-2014 The following discussion assumes that you have checked that the default can not be reached by any path through your program. This would include checking that the switch controlling expression with an essentially enum type could only have a value which is a member of the enumeration set. You have the following options depending on the requirements of your code. 1. A default is required for defensive programming purposes. Option 1a: Write a deviation for rule 2.1 that confirms that the default is not optimised out by your compiler. Option 1b: Make the switch controlling expression volatile. Code: switch ( * ( volatile enum light *) & c ) 2. No defensive programming is intended. This means that you are not concerned with rogue values being injected into your program including as a result of hardware faults etc. Option 2a: Write a deviation for rule 2.1 that confirms that the behaviour of the program is not dependent on whether the default is removed by the compiler or not. Option 2b. Write a deviation for rule 16.4 that confirms why the default is not required. Option 2c: Construct the default so that it does not contain executable code (which should include a comment stating why). For example: Code: default: 3. Restructure your code so that all code can be reached. For example by making the default include a path that is reached. |