I have a small program here that seems to detect a bug in cppcheck 2.4.1
which arises with code like panic and asserts that the dump state then loop
the system forever.
Thanks! I would suggest that if possible, don't expand assert in Cppcheck analysis. The FP is fixed if I write assert there instead. And if assert is seen Cppcheck understands the semantics better and can warn about side effects in assert condition also.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a small program here that seems to detect a bug in cppcheck 2.4.1
which arises with code like panic and asserts that the dump state then loop
the system forever.
Which results in the following error
main.c:13:2: error: Null pointer dereference: test_p [nullPointer]
test_p->i = 0;
^
main.c:10:24: note: Assignment 'test_p=NULL', assigned value is 0
struct test *test_p = NULL;
^
main.c:13:2: note: Null pointer dereference
test_p->i = 0;
^
Even though it is clear that it is impossible for main to reach the
dereference when it is NULL.
Originally discovered here with the task_next variable
https://github.com/thesofproject/sof/blob/main/src/schedule/edf_schedule.c#L98
Using the command cppcheck --platform=unix32 --force --max-configs=4096 -q
--inline-suppr --suppress=variableScope --suppress=unusedFunction
-isrc/arch/xtensa -Isrc/include --std=c89 -itest -j 16 src/
Curtis
Last edit: Daniel Marjamäki 2021-06-09
Thanks! I would suggest that if possible, don't expand
assert
in Cppcheck analysis. The FP is fixed if I writeassert
there instead. And ifassert
is seen Cppcheck understands the semantics better and can warn about side effects in assert condition also.