$ cppcheck --enable=all .\test.cpp
Checking test.cpp ...
[test.cpp:13] -> [test.cpp:17]: (style) The if condition is the same as the previous if condition
While the expression in the if test is the same, the first time it evaluates to true, while the second time (as effect of calling bar()) evaluates to false. So combining both if statements in a single if statement (which is the suggested style improvement I assume) would not be equivalent.
Last edit: Pieter Bekaert 2019-03-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your report.
I am able to reproduce the issue. Even when setting the variable directly instead of inside bar() the false positive remains.
I created trac ticket 9037
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to report a similar, yet slightly different variant of this false positive:
In case of my simple C program dupl.c, the second ("redundant") if-condition potentially evaluates to something different than the first one, because it might get modified by the function func in the previous if-body (see attached file dupl.c). This means: the if is not redudant (=> cppcheck bug).
However, I realized that cppcheck 2.1 is smart enough to not complain if the function func gets a reference (pointer) to a stack variable using the address operator & instead of a pointer into the heap (see duplstack.c):
I observe the following false positive:
test.cpp:
While the expression in the if test is the same, the first time it evaluates to true, while the second time (as effect of calling bar()) evaluates to false. So combining both if statements in a single if statement (which is the suggested style improvement I assume) would not be equivalent.
Last edit: Pieter Bekaert 2019-03-12
Thank you for your report.
I am able to reproduce the issue. Even when setting the variable directly instead of inside
bar()
the false positive remains.I created trac ticket 9037
I'd like to report a similar, yet slightly different variant of this false positive:
In case of my simple C program
dupl.c
, the second ("redundant")if
-condition potentially evaluates to something different than the first one, because it might get modified by the functionfunc
in the previousif
-body (see attached filedupl.c
). This means: theif
is not redudant (=> cppcheck bug).However, I realized that
cppcheck 2.1
is smart enough to not complain if the functionfunc
gets a reference (pointer) to a stack variable using the address operator&
instead of a pointer into the heap (seeduplstack.c
):If you think it's not the same issue than originally reported, please feel free to open another ticket in Trac.
Thanks!
Last edit: Jo 2020-09-01