Possible Misra 8.4 Flase Positive for extern variables with structs

[Sven Wienand]

We have found a strange 8.4 Misra Error which we don't know why it is happening.
I created a dummy to reproduce the error.
For the variable pubTestPointer2 it works as expected, if i remove the extern const uint8_t * pubTestPointer2; the 8.4 Error occurs pointing to the line in the c file.

For the variable with struct as data type pubTestPointer i always get the 8.4 error and it appears twice once in the header file and once in the c file.

main.h

typedef unsigned char uint8_t;
typedef struct stErrorDef
{
    uint8_t ubReturnVal;
} stError_t;
extern const stError_t * pubTestPointer;
extern const uint8_t * pubTestPointer2;

main.c

#include "main.h"
static stError_t ubTest3 = {0};
static uint8_t ubTest4 = 0;
const stError_t * pubTestPointer;
pubTestPointer = &ubTest3;
const uint8_t * pubTestPointer2;
pubTestPointer2 = &ubTest4;

I had a look in the misra.py and tried to understand the test. Trying to debug as i think it is a problem in the check itself, if not what should i change so that the code does not get the misra error, because multiple engineers didn't know what to change to fix the error, i found that the check for "record" causes both the token in the header als well as the token in the c file be in the extern_var_with_def dict. And therefore it can not be matched in the following test.

if tok.next.str == ";":
    if tok.next.isSplittedVarDeclEq or (tok.valueType and tok.valueType.type == "record"):
         self.insert_in_dict(extern_var_with_def, tok.str, tok)
     else:
         self.insert_in_dict(extern_var_without_def, tok.str, tok)
else:
     self.insert_in_dict(extern_var_without_def, var.nameToken.str, var.nameToken)

I am not sure why the check for the record is necessary, thats why i don't want to simply remove the check. After removing it for debuggin purposes the Misra Error 8.4 does not occur for pubTestPointer and if i remove the line in main.h it works like expected.

Commit where this change was done https://github.com/danmar/cppcheck/commit/ea65c09ec22b1474c4fe67333d3d0a36e0a185be

[Sven Wienand]

@danielmarjamaki any ideas?

[Daniel Marjamäki]

thanks for reporting this bug. I have created this ticket: https://trac.cppcheck.net/ticket/12978