Possible false positive for MISRA12_8.3

[kylejacksonb]

I’m getting this violation in MISRCRA C 2012:

expander_control.h 171 Expander_VerifyRegisterBit Declaration or definition is not compatible with another declaration or definition in file expander_control.c at 432:6

Here’s the code at those two locations:

bool Expander_VerifyRegisterBit(EXPAND_GPIO_t reg, uint8_t bitNumber, bool bit_compare_state)
bool Expander_VerifyRegisterBit(EXPAND_GPIO_t reg, uint8_t bitNumber, bool bit_compare_state);

The defintion of EXPAND_GPIO_t is coming from the same included file for both locations.

Looks the same to me. Any thoughts on what this could be?

[robbycbennett]

I don't see a violation with the following C code.

#include <stdbool.h>
#include <stdint.h>

typedef int EXPAND_GPIO_t; // Definition of the unknown type

bool Expander_VerifyRegisterBit(EXPAND_GPIO_t reg, uint8_t bitNumber, bool bit_compare_state);

bool Expander_VerifyRegisterBit(EXPAND_GPIO_t reg, uint8_t bitNumber, bool bit_compare_state)
{
  return true;
}

More information is needed. Are there analysis errors? Are there macros? Can we see more?

[kylejacksonb]

expander_control.h:

typedef enum
{
…
}EXPAND_GPIO_t;


bool Expander_VerifyRegisterBit(EXPAND_GPIO_t reg, uint8_t bitNumber, bool bit_compare_state);

expander_control.c:

bool Expander_VerifyRegisterBit(EXPAND_GPIO_t reg, uint8_t bitNumber, bool bit_compare_state)
{
…
}

[kylejacksonb]

@kennethctdmn Would you take a look at this check.

misraC8-3.zip

Using the included sample, I get no violations using strict, but I do get a violation using fuzzy. It's probably easier to rewrite the check entirely instead of fixing the existing check. But I would like you to see if you can get this working with the fuzzy parser.

[kennethctdmn]

@kylejacksonb I can't seem to make the current check work with the fuzzy parser.
I'll see if I can make a new one that works with both configurations.

[kylejacksonb]

That's what I figured. Don't spend too much time on this. If you think you can make it work with fuzzy, great, but if you get stuck, I'm okay with this check being strict only.

[kennethctdmn]

@kylejacksonb I've tried to utilize lex to identify the violations of this check for this to work regardless of the configuration.
However, it resulted to more false positives and addressing them becomes more complex due to variations in parameters such as namespace usage (std::) or the presence of initial values.
Given that, the current check is more precise in identifying the violations.
Should we just add a note regarding the inconsistency of the result when using fuzzy mode?

[kylejacksonb]

Yes, let's just label the check as strict only.