I suggest that we start preparations for Cppcheck 2.9. Fix stability issues and false positives primarily.
No major refactorings for a while.
I am thinking that we can try to release Cppcheck 2.9 in the second half of august.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been looking through some syntax errors. I have not seen any wrong reports. It seems pretty typical with syntax errors in unknown macros. For example:
g_assert_cmpint (serial, >, 0);
and here proper configuration is needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest that we start preparations for Cppcheck 2.9. Fix stability issues and false positives primarily.
No major refactorings for a while.
I am thinking that we can try to release Cppcheck 2.9 in the second half of august.
We seem to have a lot of newer syntaxErrors on daca that should probably be addressed.
I would like to release cppcheck-2.9 soon. Do you think it's possible on sunday (august 28th)?
I've been looking through some syntax errors. I have not seen any wrong reports. It seems pretty typical with syntax errors in unknown macros. For example:
and here proper configuration is needed.
Mhhh, we have already a configuration for this macro https://github.com/danmar/cppcheck/blob/f0ac0d891024738cf55f2ba01e9a77cac1807ca0/cfg/gtk.cfg#L179
Why do we get a syntax error?
Last edit: orbitcowboy 2022-08-27
E.g. this package clearly uses GTK, but
--library=gtkis not specified. How is that even determined?http://cppcheck1.osuosl.org:8000/ogmrip
It should be detected here: https://github.com/danmar/cppcheck/blob/cee04f4ee57a9e336755ed1b943c7e88fc8a8ca5/tools/donate_cpu_lib.py#L638
Alright, sounds good!
Can a tag be added for 2.9?