Philipp Hasper

@danielmarjamaki Yes, basically I want to suppress all but this one. Okay, concerning the Github pull requests that's a good way to go however I am uncertain how complex the dev environment will turn out to be. I will see if I find some time for that.

(I copied my question from https://stackoverflow.com/questions/60395271/ to have it in a place more suitable for feature discussions) I use cppcheck via the CLI in a continuous integration test parcours. If cppcheck fails, my job fails. Thus, I am limiting the issues cppcheck tests in order to not halt the development completely. More specifically, I currently use --enable=missingInclude,warning together with some --suppress. How can I elevate specific, non-error and non-warning issue to let cppcheck...

(I copied my question from https://stackoverflow.com/questions/60395271/ to have it in a place more suitable for feature discussions) I use cppcheck via the CLI in a continuous integration test parcours. If cppcheck fails, my job fails. Thus, I am limiting the issues cppcheck tests in order to not halt the development completely. More specifically, I currently use --enable=missingInclude,warning together with some --suppress. How can I elevate specific, non-error and non-warning issue to let cppcheck...

For everybody stumbling over the same problem, this is how I currently work around this: Prerequisites: My cppcheck command initially had the parameter --error-exitcode=1 and --output-file=CPPCheckReport.xml I removed the error-exitcode parameter from the call so the command always is successful Using xmlstartlet (http://xmlstar.sourceforge.net/) I delete all the "supicous operator ,": xmlstarlet ed -d "//error[@msg=\"Found suspicious operator ','\"]" CPPCheckReport.xml > CPPCheckReport_Sanitized.xml...

@danielmarjamaki I think a more versatile suppression than just deactivating all constStatement (because this is the ID returned for these errors) is always a good thing to have. And if it is the easy solution, that's also a plus point. I think even if the perfect solution is done, the updated suppressions will still come in handy for some future edge cases

We have the same issue with OpenCV types and also with types derived from Eigen's EMatrix. @versat Is there a way to suppress this warning globally for a code base? ideally only for the , operator?