CPPCheck always returns error code

[Christoffer Wärnbring]

I have an issue when trying to include CPPCheck in my Ci-pipe: it seems to always return the error-code even though no errors are reported (at least into the output file). Here is the complete command in a .bat-file:

@echo off
".\cppcheck\cppcheck.exe" ..\trunk\ViggenNew\Sources\Avionics ..\trunk\ViggenNew\Sources\Flightmodel --suppress=operatorEqVarError:..\trunk\ViggenNew\Sources\Include\catch.hpp --suppress=copyCtorAndEqOperator:..\trunk\ViggenNew\Sources\Include\catch.hpp --suppress=uninitMemberVar:..\trunk\ViggenNew\Sources\Include\hippomocks.h --inline-suppr --force --suppress=syntaxError --suppress=compareBoolExpressionWithInt --enable=warning 2>cppcheckerr.txt --error-exitcode=1 --template "{file}({line}): ({severity}) ({id}): {message}"
if errorlevel 1 (
echo Failure Reason Given is %errorlevel%
pause
exit /b %errorlevel%
)

When I run it and have errors in the code it will properly write the error-info in cppcheckerr.txt. If I OTOH run it and there are no errors cppcheckerr.txt will be empty cppcheck.exe will still return errorcode 1.

Help much appreciated and thanks for this very useful software and the time you gave developing it!

[Daniel Marjamäki]

hmm.. It sounds like a bug. I assume it's because there are suppressed error messages.

If you can provide a short code example and simple command line that would help us. I can add an issue in our issue tracker then.

[Christoffer Wärnbring]

Tack! This code replicates the issue. The Catch-version was whatever was most recent at 14/6 2018. I think it reports the code as if it has a syntax error or too many depths of #define (hence --force in the command-lime), but those errors are suppressed.

include "../Include/catch.hpp"

TEST_CASE("Test", "[Test]")
{

}

EDIT: There is some funky formatting going on with this post. All you should need to do to replicate the issue is include the catch.hpp file and write a test per Catch manual. The code above should be valid C++ but the pound-sign doesnt show.

[Daniel Marjamäki]

there is still not enough info for me, to look at this.

either somebody downloads catch and tries to reproduce and produce a test case, or you could help out.

is the catch.hpp the only header you need? If you copy that to another folder together with your source file then can you reproduce the problem there? if you could upload your source file and the needed headers in a zip-archive that is a good first step.

Maybe an alternative to the archive is that you try to save the preprocessor output and see if you can reproduce the problem with that..
cppcheck -E ... > file.cpp
cppcheck ... file.cpp

Then after that this archive or preprocessor output must be reduced into some small example. I would assume that it can be reduced to 3-4 lines of code. The preprocessor output would probably be pretty messy so it's lots of work to reduce it, the archive would be less work to reduce.

When we have a small code example that has 3-4 lines of code, it is possible to try to solve the problem.

[Daniel Marjamäki]

Ticket 7792 might be about the same issue. https://trac.cppcheck.net/ticket/7792

Ticket 7502 is also about the exitcode. It is not about the same problem, but possibly it is somewhat related. https://trac.cppcheck.net/ticket/7502

[Christoffer Wärnbring]

So I ran cppcheck through the debugger and it seems bool internalErrorFound in cppcheck.cpp is set to true (I guess it is meant for an error in cppcheck itself?) because a syntax error is thrown both at tokenize.cpp:8510 and 9299. I don't understand the purpose of this code, I guess it misinterpret some code within catch.hpp as either objective-c or assembly code? I am not sure it is supposed to be thrown as an internal error because it doesnt seem to output it to screen or file then? When the internalErrorFound control-flow is shown it doesnt seem to check if syntaxerror is suppressed in the commandline.