MISRA 8.7 false positives

[Richard Smith]

We have a number of MISRA 8.7 false positives. I was hoping that the update to cppcheck 2.15 would help but they still exist.

I've verified that the functions it flags are used in more than one translation unit. Any suggestions on how I would debug this further?

This is private code so I can't put up any example code.

[Daniel Marjamäki]

well how do you execute it. If you execute cppcheck on each file like so:

cppcheck --addon=misra file1.c
cppcheck --addon=misra file2.c

then such false positives are expected.

[Richard Smith]

We only call one instance of cppcheck and have all the .c files on the command line.

[Daniel Marjamäki]

You can check if the ctu-info looks reasonable..

mkdir test1
./cppcheck --cppcheck-build-dir=test1 --addon=misra --enable=style file1.c file2.c

Then try this command (where "foo" is some function you are interested in):

grep '"foo".*MisraUsage' test1/*.ctu-info

The files that use "foo" should be listed:

daniel@laptop:~/cppcheck$ grep '"foo".*MisraUsage' test1/*.ctu-info
test1/file1.a1.ctu-info:{"data":[{"file":"file1.c","name":"foo"}],"summary":"MisraUsage"}
test1/file2.a1.ctu-info:{"data":[{"file":"file2.c","name":"x"},{"file":"file2.c","name":"foo"}],"summary":"MisraUsage"}

[Richard Smith]

Thanks.

I think I see why. We have setups that are like this: device_api.c and device_driver.c. The driver methods are defined in device_api.c but device_driver.c is the sole user of those methods and there are not 2 instances of the device.

In my thinking it's referenced in 2 translation units but I can see where that could be construed as only 1 translation unit since device_driver.c is the only file to use those api calls.

Is the translation uint where the method is defined supposed to count or it it only where the method is used?

[Daniel Marjamäki]

Is the translation uint where the method is defined supposed to count or it it only where the method is used?

It's supposed to count also as far as I see.

I have this example code:

file1.h:

int foo(void);

file1.c:

#include "file1.h"

int foo(void)
{
    return 213;
}

file2.c:

#include "file1.h"
int x = foo();

[Richard Smith]

Ok. Then I appear to have false positives. I'll look into it more by looking at the .ctu-info files.

[Richard Smith]

I've determined that some of these are due to a undefined compile macro switch. ie

#if !defined(SOME_OPTION)
     // skip code
#else
    // use code
#endif

if SOME_OPTION is not defined then the usage of the methods doesn't happen and the 8.7 rule only sees the API definition.

How does cppcheck decide to define compile time switches? We are using --force but when I review all the macros listed by the Checking <file>: output I see some but not all of the macro switches used.

If I add a -D SOME_OPTION to the cppcheck command line then it fixes the issue but these options are dynamically generated for the compile by a config that happens outside of the usage of cppcheck.