cppcheck --enable=all -DLOOP=0 for_loop_hides_uninit.c
and
cppcheck --enable=all -DLOOP=0 for_loop_hides_uninit.c
both report an uninitialised variable.
But
cppcheck --enable=all -DLOOP=2 for_loop_hides_uninit.c
doesn't report the uninitialised variable.
Note: original code had a variable rather than a #define and behaved as -DLOOP=2
With Cppcheck 1.87 i can reproduce this.
With the latest git head Cppcheck does not report any uninitialized variable for this example, not even inconclusive.
Maybe Cppcheck avoids to report a false positive here because it can not now the value of argc. But otherwise the else branch would be redundant if argc is always greater than 1.
IMHO Cppcheck should warn in this case because there is clearly at least one path where the variable can be uninitialized.
The latest Cppcheck does not warn for this reduced example that does not use a macro but uses 1 instead of the LOOP macro:
$ ./cppcheck --enable=all --inconclusive for_loop_hides_uninit.c
Checking for_loop_hides_uninit.c ...
(information) Cppcheck cannot find all the include files (use --check-config for details)
And even when disabling the for loop Cppcheck does not warn. In this case the variable is always uninitialized:
$ ./cppcheck --enable=all --inconclusive for_loop_hides_uninit.c
Checking for_loop_hides_uninit.c ...
(information) Cppcheck cannot find all the include files (use --check-config for details)
Looks like a regression. What would you say Daniel?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
cppcheck --version
Cppcheck 1.87
for() loop seems to hide uninitialized variable
cppcheck --enable=all -DLOOP=0 for_loop_hides_uninit.c
and
cppcheck --enable=all -DLOOP=0 for_loop_hides_uninit.c
both report an uninitialised variable.
But
cppcheck --enable=all -DLOOP=2 for_loop_hides_uninit.c
doesn't report the uninitialised variable.
Note: original code had a variable rather than a #define and behaved as -DLOOP=2
Bother second -DLOOP=0 should be -DLOOP=1
With Cppcheck 1.87 i can reproduce this.
With the latest git head Cppcheck does not report any uninitialized variable for this example, not even inconclusive.
Maybe Cppcheck avoids to report a false positive here because it can not now the value of
argc
. But otherwise theelse
branch would be redundant ifargc
is always greater than 1.IMHO Cppcheck should warn in this case because there is clearly at least one path where the variable can be uninitialized.
The latest Cppcheck does not warn for this reduced example that does not use a macro but uses 1 instead of the LOOP macro:
Output
And even when disabling the for loop Cppcheck does not warn. In this case the variable is always uninitialized:
Looks like a regression. What would you say Daniel?
Maybe a slightly related ticket:
https://trac.cppcheck.net/ticket/8276
yes we should warn in both cases. Thanks.. I will try to look at this asap.. or create a ticket.
I created this ticket: https://trac.cppcheck.net/ticket/9030
We should add proper ValueFlow analysis for this.
I am very grateful that this false negative was reported.
To clarify... we need to check that
argc
is unchanged in the loop. Imagine:Here it is not conclusive if it would be possible with uninitialized
value
after the loop...