Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Questions about Rule 2.1
#1
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.
<t></t>
#2
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.
Posted by and on behalf of the MISRA C Working Group
#3
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.
<t></t>
#4
Thank you for your query. We will reply after our next working group meeting which is on the 3rd December.
Posted by and on behalf of the MISRA C Working Group
#5
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 )
This prevents the compiler from possibly removing the default statement because it is now reachable.


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:
       /* no default required as not concerned with .... */
        break;
This means that it does not matter if the compiler removes the default path or not.


3. Restructure your code so that all code can be reached. For example by making the default include a path that is reached.
Posted by and on behalf of the MISRA C Working Group


Forum Jump:


Users browsing this thread: 3 Guest(s)