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...

Yes. This works. Thank you. I was only looking at the commit message which only includes the track ticket so I thought that was the accepted format.

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

Similar to my MISRA 8.7 comment we have what seem like 5.9 false positives. It's not clear to me why the addon thinks the identifiers are not unique. The function referenced appears to be declared static in all the cases where it is used. If I were to look into the .ctu-info files what I'm I looking for to find where it thinks the overlapping identifiers are.

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...

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

I'm not sure if this was the right place but I've filed: https://github.com/conda-forge/cppcheck-feedstock/issues/94

Who makes the conda packages then?