Is there a bug regarding MISRA Rule 2.2 (Dead Code)?

MISRA-C 2012 Rule 2.2 says: There shall be no dead code.

There is an example appended to the text which explains the rule.

To keep this question as short as possible, I have shortened the example down to:

```

void f(void){

uint16_t x;

/*...*/

x=3; // Non-Compliant

}

```

However, Polyspace is not able to detect this assignment as dead code.

To be clear: MISRA-C 2012 provides the example above for a dead code violation and Polyspace does not find this violation.

This should be a bug. I am not sure if this is the right place to post/ask this. Is there a bug-tracker or any place where I can file an issue for this?

Am I missing something here?

Answer 1

[Anirban]

Hi,

I was able to detect the rule violation on this code:

#include <stdint.h>

void f(void){

uint16_t x;

/*...*/

x=3; // Non-Compliant

}

I found the violation using Polyspace Bug Finder. It was not detected with Polyspace Code Prover. Based on the Polyspace documentation page for MISRA Rule 2.2, this is expected.

In general, Polyspace Bug Finder is the recommended tool for detecting coding standard violations (search for MISRA on this page). If you compare the MISRA C:2012 support between Bug Finder and Code Prover, you will see that Bug Finder supports all coding rules while Code Prover does not support a subset. Even within the supported rules, it is possible that Code Prover does not detect a subset of issues.

Code Prover is primarily meant for exhaustive checking of certain types of run-time errors. Finding coding standard violations is more akin to bug finding, and therefore, Bug Finder is the tool recommended for this purpose. Even though both Bug Finder and Code Prover started out with similar support for coding standards, it seems Bug Finder has forged ahead and Code Prover left behind. If you have a license for Code Prover, you also have a Bug Finder license (since it comes as a base product).

If you do not see the violation with Bug Finder, there is another remote possibility that the file did not compile for some reason. Bug Finder shows a subset of coding standard violations before (or along with) compilation, but shows a few others only if the file successfully compiled.

As for whether you can report bugs, yes, you can report a bug here: https://www.mathworks.com/support/contact_us.html . You can look for fixed bugs here: https://www.mathworks.com/support/bugreports/ .

[Christian Wedding]

Related to this question, Bug Finder will not detect an assignment during declaration as dead code, although the variable is never used.

This Code will be detected as dead code:

{
  volatile uint8_t rule_02_02;
  rule_02_02 = 89;
  return;
}

However, this code is undetected:

{
  volatile uint8_t rule_02_02 = 89;
  return;
}

I could not find any information on this particular example on google or https://de.mathworks.com/help/bugfinder/ref/misrac2012rule2.2.html either.

Is this behavior correct?

[Anirban]

There is probably an optimization at work which prevents the analyzer from seeing the initialization at declaration (for this specific checker). This has been reported and will probably be fixed in a coming release.

[Christian Wedding]

Thank you for your feedback!

Another code that goes undetected is this one:

static uint16_t times_three(const uint16_t *x)
{
  volatile uint8_t rule_02_02_a;
  rule_02_02_a = 102; // DEAD CODE UNDETECTED
  return 3u * (*x);
  uint8_t rule_02_01_a = 23;
  rule_02_01_a += 4U;
  (void) printf("%d\n", rule_02_01_a);
}