MISRA Discussion Forums - 8.2 Unused code

2.2 Dead code, 'operations' and casts

Thu, 21 Oct 2021 13:39:50 +0000

Hi,

I have a question regarding the meaning of 'Dead Code' within MISRA-2012. My question is, I believe, somewhat similar to this thread, but the contents of that thread appear to be missing such that I cannot determine what the exact question was, nor the answer.

My questions are:

1) What is an 'operation'? 'Dead code' is defined in terms of 'operations', but 'operation' is never defined in MISRA.

2) Does an addition/subtraction of a constant 0 to a value (either literally or by macro) count as dead code? This sometimes happens in the context of register offsets where the first offset is 0.

Code:
#define BASE_ADDR 0x80000000u

#define CTRL_OFFSET 0x0u

uint32_t a = BASE_ADDR + 0x0u; // Dead addition?

uint32_t b = BASE_ADDR + CTRL_OFFSET; // Dead addition?

3) Does a cast of a value to it's own type count as dead code?

Code:
uint8_t a = (uint8_t)0u; // Dead cast? (Type of 0u is UTLR)

uint8_t b = (uint8_t)a; // Dead cast? (Type of a is uint8_t)

4) Does an explicit cast to a type for which implicit conversion is allowed count as dead code?

Code:
uint8_t a = (uint8_t)0; // Dead cast? (Type of 0 is STLR, but assignment is permitted by exception)

uint16_t b = (uint16_t)a; // Dead cast? (Conversion to wider type of same signedness is allowed implicitly)

Rule 2.5 and unused macro parameter

Thu, 12 Mar 2020 15:04:00 +0000

Rule 2.5 states "A project should not contain unused macro declaration".

Forum post https://www.misra.org.uk/forum/viewtopic...216&t=1571 acknowledges that Rule 2.5 should be "A project should not contain unused macro definition", however a change to "A project should not contain unused macro identifier" would cover both the original intent and also catch the following coding error without compromising rule decidability:
[code]
/* Macro containing coding error - macro parameter pin is unused */
#define SET_PIN(pin, polarity) \
((GPIO->PIN[pin_number] & ~PIN_Msk) | (polarity

Rule 2.1 : Checking for all possible error status - Is a deviation reasonable for this?

Wed, 19 Sep 2018 17:30:54 +0000

Hello,
I have the following piece of code for which I get a MISRA Rule 2.1 error. I am considering a deviation for this - All possible error status from a function call can be checked even if the function does not return all possible error statuses. Can you please provide feedback on if this is a reasonable deviation?

(Btw, this is my first post - please feel free to let me know if this is outside the scope here)

Example:

Code:
#include "stdafx.h"

typedef enum ErrStatus {

    Success = 0,

    Err_1,

    Err_2

} ErrStatus;

ErrStatus f(int x) {

    if (x < 0) {

        return Err_1;

    }

    else

    {

        return Success;

    }

}

    int main()

    {

        ErrStatus x = f(5);

        switch (x)

        {

        case Err_1:

            printf("err 1"); break;

        case Err_2:

            printf("err 2 "); break;  /* Is this dead code ? */

        default:

            printf("Success"); break;

        }

    }

Rule 2.5 unsued macro definition

Fri, 08 Sep 2017 08:55:01 +0000

Hi,

I have the following code:

Code:
cfg.h:

/* uncomment next line if the feature is needed for your project */

/* #define activate_feature */

-----

feature.h:

#ifdef activate_feature

#ifdef protected_feature

/* limited visibility stuff */

[...]

#endif /* protected feature */

#endif /* activate feature */

-----

feature.c:

#define protected_feature

#include "cfg.h"

#include "feature.h"

#ifdef activate_feature

[...]

#endif /* activate feature */

The code is part of a library which is used in various projects which shall be MISRA2012 compliant.
Based on each project a different version of cfg.h is used which configures the project specific needs.
In projects where activate_feature is not defined I always got a claim from my code checking tool that the macro protected_feature is not used.
Is this really a violation of Rule 2.5 or is the code checker wrong?
If it is a violation how to handle code where parts a selected by conditional compiling?

Rule 2.2 dead code and empty function

Mon, 26 Jun 2017 05:59:59 +0000

An empty function is the dead code? for example:
/*file1.c*/
void vidNextStep(void)
{

}
/*file2.c*/
void test(void)
{
vidNextStep();
}
I think an empty function is the dead code, because it shall be called, it means that it shall execute, but It shall not affect program behavior.
Do it?

Rul 2.5: Definition of a project and unused code

Tue, 18 Apr 2017 20:56:49 +0000

This questions would rather belong to a specific forum for discussions of glossary terms but I could not find the appropriate section. My original question deals with the definition of "Project". I'll use example of unused code, but this issue could also be discussed in a context of other rules.

Let's say, I build an executable that makes use of a library, whose headers, say, contain a certain macro definition. This macro is not used anywhere in the source code of the executable directly, but it is used somewhere inside the library.

Is this situation compliant with Rule 2.5?

What if this library is actually a third party library whose source code is not available? Should the library itself be MISRA-compliant for the using code to be compliant (and thus definition of a "project" should also contain libraries and not only an executables)?

Rule 2.5 vs. include guards

Mon, 27 Feb 2017 11:54:10 +0000

Hi.
It is not completely clear what is meant by use of a macro in Rule 2.5. There is definition of a use of an expression in the Glossary, but not of a macro.
If taken literally, rule 2.5 means that standard include guards are forbidden:

#ifndef HEADER_H
#define HEADER_H // Not used unless another #ifndef is encountered somewhere inside
...
#endif

Possible inaccurate example?

Thu, 17 Nov 2016 17:34:39 +0000

The following is the example reported for Rule 2.2 (dead code):

Quote:In this example, it is assumed that the object pointed to by p is used in other functions.

Code:
extern volatile uint16_t v;

extern char *p;

void f (void )  {

   uint16_t x;

   (void) v;  /* Compliant - v is accessed for its side effect * and the cast  to void is permitted by exception */

   (int32_t) v; /* Non-compliant - the cast operator is dead */

   v >> 3;     /* Non-compliant - the >> operator is dead */

   x = 3;      /* Non-compliant - the = operator is dead * - x is not subsequently read */

   *p++;       /* Non-compliant - result of * operator is not used */

   (*p)++;     /* Compliant - *p is incremented */

}

I'm not sure that last but one statement represents a non-compliance. In fact, the expression *p++ is treated as *(p++), as the precedence of postfix ++ is higher than *. Indeed the result of * operator is not used, but p value results permanently increased, and p is a global variable. How can be stated that it is not compliant, alias dead code, i.e. "...whose removal would not affect program behaviour"?

Rule 2.2 - dead code

Mon, 25 Jul 2016 13:16:44 +0000

Does the following code example violate Rule 2.2, due to the left shift?

[code]#define BITSET(reg, bit) ((reg) |= (uint8_t)(1u

declaration or definition

Thu, 23 Jun 2016 00:38:41 +0000

Rule 2.3 mentions "type declaration".
Rule 2.5 mentions "macro declaration".

But I think the type should not be declared but defined by "typedef".
I also think the macro should not be decalred but defined by "#define".

MISRA Study Group in Japan is confused when translating the guidelines.

Thank you

Rule 2.4 and tag used in typedef

Fri, 30 Oct 2015 09:05:45 +0000

Would the following examples be compliant with rule #2.4?

Code:
typedef struct cood cood_t;

 struct cood {                    // here,  is the tag "cood" compliant?

    uint8_t  id;

 };

Rule 2.4 and forward declarations

Tue, 21 Apr 2015 22:08:44 +0000

Would the use of tags for forward declarations be considered a failure of this rule, if used such as

Code:
struct test;

typedef struct test test_T;

typedef bool (*Callback_T)(test_T const * p_test);

struct test

{

    uint32_t var;

    Callback_T callback;

};

For consistency in type usage, I would prefer to utilize the typedef whenever referring to this structure, including in the callback definition, but this leads our analysis tools to flag that "test" is only used in the typedef.

else statement about Rule2.1

Tue, 28 Oct 2014 06:57:52 +0000

I have a question about Rule2.1.

Are these samples correct?
The else statement is null statement or not.

sample_1
if ( a= 5 ) {
y=3;
}else{
y=0; /* not compliant */
}

sample_2
if ( a= 5 ) {
y=3;
}else{
; /* compliant */
}

I think if the else statement is null statement the code is reachable.
Is is correct?

And how about is default label?

In case all case is coded,if default label has null statement , the code is reachable.
Is it correct?

Please teach me.

Regards

Rule 2.5 Does #undef count as a "use"

Thu, 09 Oct 2014 08:31:50 +0000

Rule 2.5 Is #undef considered a â€œuseâ€ of a macroâ€?
For example

Code:
#define M1 This

   #define M2 That

   #undef M1

   use( M2 );

Is 'M1' unused and therefore violate rule 2.5, or does the #undef count as a use of M1?

Is a function parameter â€œusedâ€ if cast to void?

Thu, 09 Oct 2014 08:29:19 +0000

Does the following violate rule 2.7 (There should be no unused parameters in functions)?

Code:
void fn ( int32_t param )

{

   ( void )param;

}