MISRA Violation 12.5 when using && and || in if-statement

Question

I'm working on a project where we are appling MISRA 2004.

On most of the violations I got the reason, but one I don't understand:

Its in the if-statement with && and || operations.

Example:

uint8 getValue()
{
   // Some algorithm, simplified with return 1
   uint8 someValue = 1u;
   return someValue;
}
int main(int argc, char *argv[]) {
    uint8 currentState = 0u;
    uint8 var_a = getValue();
    uint8 var_b = getValue();
    uint8 var_c = getValue();
    uint8 var_d = getValue();

    const uint8 const_a = 1u;
    const uint8 const_b = 2u;
    const uint8 const_c1 = 3u;
    const uint8 const_c2 = 30u;
    const uint8 const_d = 4u;

    if ((var_a == const_a) && (var_b == const_b) && ((var_c == const_c1) || (var_c == const_c2)) && (var_d == const_d))
    {
        currentState = 1;
    } else 
    {
        currentState = 2;
    }
}

This gives me twice the MISRA violation to rule 12.5 non-primary expression used with logical operator. Both are in the line with the IF-Statement

I don't see a problem with this if-statement, despite its a bit long.

Does anybody know, whats wrong here and how to solve that violation?

Edit: I adjusted the example a bit. I also noticed, that I get only one error if I simplify the if statement to:

if ((var_a == const_a) && ((var_c == const_c1) || (var_c == const_c2)) && (var_d == const_d))

And no violation if its changed to:

if ((var_a == const_a) && ((var_c == const_c1) || (var_c == const_c2)))

Caustic

What exactly are var_X and const_X in your case? – Locomobile

I wonder which of these is considered "non-primary". My guess is the two or'ed expressions. – Cavernous

@UlrichEckhardt An operand which is surrounded by parenthesis is always a primary expression, as per C17 6.5.1. – Supercolumnar

@Jabberwocky: They are both uint8 – Caustic

@UlrichEckhardt: I got two error in this line, both 12.5 non primary expression. I have some other if statements, they are all fine, just the one with || have problmens – Caustic

If you're using not somewhere, you'd be non-compliant: if (x && !y); // Noncompliant – Titus

I'd then second Lundin's answer, that it's a false positive. However, the above is clearly not your actual code (I hope), so I wonder if you have tried to extract a minimal reproducible example from your code? – Cavernous

@SimonGarfunkel Well then I believe you might have multiple violations of rule 10.1, but that doesn't explain the warning you are getting. – Supercolumnar

@Lundin, no I use this if-statement two times like in the example, and I have four misra violations 12.5, for each statement two. – Caustic

@UlrichEckhardt, its a state machine, which transitions from one state into another, depending on the received values. So I actually have this exact if-statement. The only difference is, the namine of the variables and constants. – Caustic

Edit the question to provide a minimal reproducible example. – Toritorie

@EricPostpischil I edited the example to a minimal reproducable example. Sorry for the lazy previous example. – Caustic

@SimonGarfunkel: Did you confirm the violation message occurs with the minimal reproducible example? – Toritorie

@EricPostpischil Yes i get two MISRA 12.5 violations in the line with the if statement, if I check the MISRA 2004 on the provided example. – Caustic

Answer 1

This appears to be a false positive by your static analyser. Your code is compliant.

The rationale for MISRA C:2004 12.5 (and the equivalent rules in the 2012 version) is to avoid situations where operator precedence might not be obvious. Overall MISRA insists that sub-expressions involving binary operators ("complex expressions") should always have parenthesis.

In case of the boolean && and || operators specifically, the rule 12.5 allows chaining multiple of them in the same expression, but not mixing && and || in the same expression without parenthesis, since they have different precedence.

Had you written && (var_c == const_c1) || (var_c == const_c2) && then the code would be non-conforming. You didn't however, and you did also put parenthesis around the inner sub-expressions.

Supercolumnar