Recent changes to Project cppcheck (original) (raw)

Sorry for the late reply. Here's an updated overview.

We need to add the suppressions in https://github.com/danmar/cppcheck/pull/8008 so it can be merged.

Still to be done for simple 1.6.4:
https://github.com/danmar/simplecpp/pull/599 (basically ready - still want to get it a closer look tomorrow)

regarding https://github.com/danmar/simplecpp/issues/556 / https://github.com/danmar/simplecpp/pull/475
I think it will be fine to release it without having the MinGW CI in-place and the known issues fixed. It only affects simplecpp since it is not hooked up in Cppcheck yet so the scope is also limited. Since the current CI does not fail and we already missed earlier issues it is obviously not a primary (or possibly even secondary) platform. It should definitely be fixed for the future 1.6.x/2.20 release (we should backport it for a patch release though). I am also pretty sure adapting the MinGW CI in Cppcheck will unearth more issues.

simplecpp 1.6.4 merge is already prepared in https://github.com/danmar/cppcheck/pull/8000

https://github.com/danmar/cppcheck/pull/7962 can also be applied after simplecpp 1.6.4 has been merged.

I still feel very strongly about reverting https://github.com/danmar/cppcheck/pull/7658 - see https://github.com/danmar/cppcheck/pull/8018. Let's keep any discussion in those tickets.

Integrating simplecpp 1.6.4 (yet to be tagged) would fix the crash from https://trac.cppcheck.net/ticket/14268

I would like to release soon. Customers are waiting for some of the bug fixes. What more do you feel we need to fix before the release? Imho getting latest simplecpp fixes into cppcheck should be pretty high prio. I can help out and I can ask ludvig, oleksandr and swasti to work on some tasks if there are suggestions..

Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/14315

That seems to be a true positive. The multiplication is done using 32 bits, and the result is assigned to a 64 bit value. In case of a = 5, cppcheck knows that no overflow can occur.

I'm using cppcheck 2.18.0

Here is code:

static const int i = 0; int main() {  assert(i == 0); } 

When running cppcheck --enable=style I have issue:

cppcheckbug_4:4:10: style: The comparison 'i == 0' is always true. [knownConditionTrueFalse] assert(i == 0);  ^ cppcheckbug_4:1:22: note: 'i' is assigned value '0' here. static const int i = 0;  ^ cppcheckbug_4:4:10: note: The comparison 'i == 0' is always true. assert(i == 0); 

Although the cppcheck has right, the assert is to make sure the variable is 0 and e.g. no one will change it to other value because code below the assert works only for 0. That's the idea of assert and the issue shouldn't be raised here.

I'm using cppcheck 2.18.0

Here is code:

// scanf and printf are just to get rid of unused and uninitialized variable int main() {  uint32_t a;  scanf("%u", &a);  uint32_t i = a, j = a;  uint64_t k = i * j;  printf("%lu", k); } 

When running cppcheck --enable=style I have error:

style: int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. [truncLongCastAssignment] uint64_t k = i * j; 

There's no issue when I remove the scanf and assign some number to the a variable e.g. uint32_t a = 5;

I didn't quite understand the solution of the OP. "A quick solution that wasn't immediately obvious to us was to move all our external libraries to an external directory and updating our include paths accordingly"

The idea is to not let cppcheck see the Eigen headers.

Hello,
sorry to move back that topic. I encounter the same issue with the usage of the eigen library.

include/eigen/src/plugins/CommonCwiseBinaryOps.h:19]: (error) syntax error
It's exactly the same issue on operator- or operator+ or any sign after operator.

I didn't manage to create an eigen.cfg that works. Don't know how to make it work.
I try to do
<define name="EIGEN_MAKE_CWISE_BINARY_OP(operator-,OPNAME)" value="">
It works with a simple sample of code, but don't work with CommonCwiseBinaryOps.h
My project is currently running with cppcheck 2.14.</define>

I didn't quite understand the solution of the OP. "A quick solution that wasn't immediately obvious to us was to move all our external libraries to an external directory and updating our include paths accordingly"
Can someone enlighten me?

Thank you for confirming.