Cppcheck output changed in 2.4.1, breaks suppressions

[Linus]

Hi,

I've encountered a problem when going from 2.3.1 to 2.4.1. When running cppcheck (from Windows command line), using the following syntax (somewhat shortened for clarity):
cppcheck.exe --project=build\some_arch\compile_commands.json --suppressions-list=cppcheck_suppressions.txt --output-file=build\some_arch\cppcheck_output.txt

...the output in build\some_arch\cppcheck_output.txt differs when toggling between running 2.3.1 and 2.4.1 which breaks suppressions. When using 2.3.1 output uses relative paths such as "src\cpc.c:347:4:" while 2.4.1 produces absolute paths such as "C:\gitrepos\myProject\src\cpc.c:347:4:".
My suppression file contains a single directive that I've used to exclude checking all source code under myProject's "lib" folder: *:lib/* This works in 2.3.1, but not in 2.4.1.

As the output for files in the lib folder no longer starts with lib/ when using 2.4.1, the suppression is not effective. At least that is what I think is happening. The compile_commands.json file produced is identical for 2.3.1 and 2.4.1.

I've tried to find information about any intentional change in 2.4/2.41 but could not find any. Am I missing some sort of configuration option here or is this a bug?

[Daniel Marjamäki]

ouch :-(

This was not a intentional breakage..

quick question .. does it work if you add the -rp flag? like -rp=C:\gitrepos\myProject?

[Linus]

I tried the -rp flag but it didn't affect the output. I also tried moving compile_commands.json to the root of the project using --project=compile_commands.json which also didn't affect the output, still absolute paths.

Removing the --project flag and just providing a single source as input on the command line , e.g. src\cpc.c produces the correct relative path in the output.

[Daniel Marjamäki]

hmm I am afraid I don't see a quick solution that you can use now.

but it seems like a bug that we want to fix in cppcheck-2.5

[Daniel Marjamäki]

hmm.. the -rp flag works in linux it should be possible to make it work in Windows..

[Daniel Marjamäki]

I am not sure why it does not work for you but the -rp seems to be case sensitive. that is unfortunate.

I have cppcheck source code on my computer in the path C:\Users\danielm\cppcheck.

With this command:

C:\Users\danielm\cppcheck>cppcheck --project=b1\compile_commands.json --file-filter=*/analyzerinfo.cpp --enable=all --inconclusive

I get such error:

C:\Users\danielm\cppcheck\lib\analyzerinfo.cpp:128:0: style: The function 'analyzeFile' is never used. [unusedFunction]

With this command:

C:\Users\danielm\cppcheck>cppcheck --project=b1\compile_commands.json --file-filter=*/analyzerinfo.cpp --enable=all --inconclusive -rp=C:\Users\danielm\cppcheck

The error message is:

lib\analyzerinfo.cpp:128:0: style: The function 'analyzeFile' is never used. [unusedFunction]

[Daniel Marjamäki]

My suppression file contains a single directive that I've used to exclude checking all source code under myProject's "lib" folder: :lib/ This works in 2.3.1, but not in 2.4.1.

An alternative might be to change the suppression:

*:*/myProject/lib/*

[Linus]

(I've accidentally written Cppcheck 2.3.1 in my original post but it I really was going from 2.3 to 2.4.1).

An alternative might be to change the suppression:
*:*/myProject/lib/*

As we are multiple developers working on this 'myProject' project I need to keep things strictly relative or be able to use wildcards as different developers clones the project to different paths and even different names on the project's root folder. It may not always be contained in 'myProject'. I modified your suggestion into the following to be path agnostic:

*:*/lib/*

...which worked! Cppcheck 2.4.1 honors that suppression. But it is not backwards compatible with Cppcheck 2.3 for which it does not work.

Edited: skipping the first slash and just do *:*lib/* works with both versions.

From my point of view it would be best if Cppcheck kept outputting relative paths as it did before as that makes it easier to use out of the box in a multi developer environment. And to retain compatibility with older versions if Cppcheck has outputted relative paths for a long time.

I'm driving the invocation of cppcheck from a makefile and although it is possible to provide the -rp flag with the current directory paths it is also an extra step to get it working.

I haven't tried it in Linux, but I guess the behavior (output) should be consistent between the platforms, regardless of what that behavior ends up being.
I did an extra check that I provided the path with correct casing when trying -rp in Windows, but I still it wouldn't work (also tried with/without trailing backslash).

And many thanks for all your hard work with this tool!

[Daniel Marjamäki]

From my point of view it would be best if Cppcheck kept outputting relative paths as it did before as that makes it easier to use out of the box in a multi developer environment.

Yes.

But I believe we switched to absolute paths in the compile database import to solve some problems. I'd rather not introduce those problems again.

If we can convert to relative paths later somewhere I think that would be preferable. I think it's something to investigate before 2.5 release.

[Richard Smith]

This is a really good example of where a cppcheck stable series would be helpful. Your work around might help but lets assume it does not. If you fix this regression in main then in order for Linus to use it running a main build would be required, but you previously stated in another thread.

it will take a while before the release. I feel that latest head is rather experimental.

So in order to get this fix Linus would have to run experimental versions of cppcheck. This is not a good user experience. A stable branch would resolve this. The fix for this would be applied to stable and allow running of 2.4 without picking up all the current experimental changes.