I am not sure if we should keep the --clang option.
In theory it's a really nice feature to have. But I fear that it would take considerable effort to implement it properly.
For instance we should add more testcases in test/cli/test-clang-import.py. I envision that we need 100's of test cases and that there will be lots of tweaks needed to make those work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For information, I tested adding the code in https://trac.cppcheck.net/ticket/9867 to test/cli/test-clang-import.py ... it fails. As the attachment shows there is lots to fix to make that work.
I my self have never used the --clang option. I know you some automated testing of source packages. Do you run --clang option on any of those? Does it show a big difference in any of those cases?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
adding --clang to daca@home has been on my wishlist.
well at the moment the option is "experimental" .. we could leave it as an "experimental" option for a while. If there is interest to sponsor the development I am not against that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah I think it would be good to get some --clang input eather way. Sound like to me it is worth wild to keep it as a experimental option.
Upgrading daca@home and --clang support might make for good google summer of code projects. It would be nice to have a user interface to daca@home data for those of us like my self who have an addiction to large data sets and statistics.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the big things I used to do at work I called cppcheck-athon. Where I would run multiple older versions of cppcheck on the same code baes. This was to prove the point that there isn't a good reasons to uses old versions of a static analyses tool. In the case of cppcheck there are 3 to 4 releases a year. I used to just point co workers to this link https://trac.cppcheck.net/report/6 which was great to quickly show people look at all the content that was added in the versions of cppcheck. I think it was a project I was on where they were stuck on red hat 6 and they weren't upgrading because it was for a rocket launch that was launching in 2019 and had some drivers that were holding them back. So the rpm for cppcheck was really out of date I think it was version cppcheck-1.63.
I used to mainly run it on our code bases at the time, but I did find one that I ran on the the Juliet 1.3 SARD C/C++ Data Set that I feel I can post the results of on here. Useally when running on our code bases the results were more clear. To me it might be intresting to put some of this data in the cppcheck manual.
time ./cppcheck -j 7 --force --enable=all ../../SARD/C >& cppcheck_VERSION _out.out
This version was run with the –inconclusive option. –dump is what allows me to run the addons.
time ./cppcheck -j 7 --dump --inconclusive --force --enable=all ../../SARD/C >& cppcheck_1.87_inc_out.out
./cppcheck-1.87/cppcheck_1.87_inc_out.out :E/W Total: 11592 Error: 7755 Warning: 3837 Perf: 297 Style: 143464
Checking 3 of the addons for cppcheck 1.87 found the following
find ./ -name "*.dump" | xargs -n 1 -P 1 /opt/rh/rh-python36/root/usr/bin/python3.6 /users/jborland/Projects/CPPCheck/cppcheck-1.87/addons/threadsafety.py >& ~/threadCheck_out.out
Thread
72 (warning): Local static object: badLock [threadsafety]
400 (warning): Local static object: dataBuffer [threadsafety]
132 (warning): Local static object: goodLock [threadsafety]
2 (warning): Local static object: HelperClass [threadsafety]
4 (warning): Local static variable: charString [threadsafety]
1200 (warning): Local static variable: dataBuffer [threadsafety]
Cert
1460 (style): Attempt to cast away const [cert-EXP05-C]
36 (style): Bitwise operator is used with a Boolean-like operand [cert-EXP46-c]
3025 (style): Do not use the rand() function for generating pseudorandom numbers [cert-MSC30-c]
224 (style): Ensure that integer conversions do not result in lost or misinterpreted data (casting -1 to unsigned long) [cert-INT31-c]
36 (style): Ensure that integer conversions do not result in lost or misinterpreted data (casting 4194304 to signed char) [cert-INT31-c]
MISRA Just a warning the misra check took 3 or 4 hours and generated 14Gigs of data. If you have lots of cores you could get the time down my check was single threaded just because
18 [misra-c2012-16.3]
18 [misra-c2012-7.1]
36 [misra-c2012-11.4]
66 [misra-c2012-11.9]
72 [misra-c2012-21.5]
102 [misra-c2012-16.6]
108 [misra-c2012-10.1]
138 [misra-c2012-16.4]
348 [misra-c2012-15.6]
410 [misra-c2012-21.10]
514 [misra-c2012-10.8]
580 [misra-c2012-3.1]
663 [misra-c2012-4.1]
756 [misra-c2012-13.4]
906 [misra-c2012-20.13]
1146 [misra-c2012-15.5]
1356 [misra-c2012-11.3]
1460 [misra-c2012-11.8]
2665 [misra-c2012-20.1]
3268 [misra-c2012-11.5]
3695 [misra-c2012-15.7]
6316 [misra-c2012-5.1]
9666 [misra-c2012-19.2]
12032 [misra-c2012-15.1]
15216 [misra-c2012-17.8]
16008 [misra-c2012-12.3]
23404 [misra-c2012-21.7]
33400 [misra-c2012-18.8]
37422 [misra-c2012-17.1]
98967 [misra-c2012-21.8]
111229 [misra-c2012-21.3]
118119 [misra-c2012-12.1]
122987 [misra-c2012-21.6]
191604 [misra-c2012-5.4]
208601 [misra-c2012-5.3]
217437 [misra-c2012-14.4]
411537 [misra-c2012-10.4]
95717279 [misra-c2012-5.2]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure if we should keep the
--clangoption.In theory it's a really nice feature to have. But I fear that it would take considerable effort to implement it properly.
For instance we should add more testcases in test/cli/test-clang-import.py. I envision that we need 100's of test cases and that there will be lots of tweaks needed to make those work.
For information, I tested adding the code in https://trac.cppcheck.net/ticket/9867 to test/cli/test-clang-import.py ... it fails. As the attachment shows there is lots to fix to make that work.
Last edit: Daniel Marjamäki 2020-09-05
I my self have never used the --clang option. I know you some automated testing of source packages. Do you run --clang option on any of those? Does it show a big difference in any of those cases?
adding
--clangto daca@home has been on my wishlist.well at the moment the option is "experimental" .. we could leave it as an "experimental" option for a while. If there is interest to sponsor the development I am not against that.
Yeah I think it would be good to get some --clang input eather way. Sound like to me it is worth wild to keep it as a experimental option.
Upgrading daca@home and --clang support might make for good google summer of code projects. It would be nice to have a user interface to daca@home data for those of us like my self who have an addiction to large data sets and statistics.
Yes.
I am willing to share that info if anybody wants to have that. if there is some missing report feel free to update the donate-cpu-server script.
One of the big things I used to do at work I called cppcheck-athon. Where I would run multiple older versions of cppcheck on the same code baes. This was to prove the point that there isn't a good reasons to uses old versions of a static analyses tool. In the case of cppcheck there are 3 to 4 releases a year. I used to just point co workers to this link https://trac.cppcheck.net/report/6 which was great to quickly show people look at all the content that was added in the versions of cppcheck. I think it was a project I was on where they were stuck on red hat 6 and they weren't upgrading because it was for a rocket launch that was launching in 2019 and had some drivers that were holding them back. So the rpm for cppcheck was really out of date I think it was version cppcheck-1.63.
I used to mainly run it on our code bases at the time, but I did find one that I ran on the the Juliet 1.3 SARD C/C++ Data Set that I feel I can post the results of on here. Useally when running on our code bases the results were more clear. To me it might be intresting to put some of this data in the cppcheck manual.
time ./cppcheck -j 7 --force --enable=all ../../SARD/C >& cppcheck_VERSION _out.out
./cppcheck-1.63/cppcheck_1.63_out.out :E/W Total: 10250 Error: 9870 Warning: 380 Perf: 16813 Style: 73435
./cppcheck-1.74s/cppcheck_1.74s_out.out :E/W Total: 18907 Error: 14328 Warning: 4579 Perf: 190 Style: 110566
./cppcheck-1.82/cppcheck_1.82_out.out :E/W Total: 14138 Error: 10338 Warning: 3800 Perf: 214 Style: 124467
./cppcheck-1.83/cppcheck_1.83_out.out :E/W Total: 14201 Error: 10401 Warning: 3800 Perf: 214 Style: 124467
./cppcheck-1.86/cppcheck_1.86_out.out :E/W Total: 11511 Error: 7713 Warning: 3798 Perf: 296 Style: 127211
./cppcheck-1.87/cppcheck_1.87_out.out :E/W Total: 11489 Error: 7698 Warning: 3791 Perf: 296 Style: 140617
This version was run with the –inconclusive option. –dump is what allows me to run the addons.
time ./cppcheck -j 7 --dump --inconclusive --force --enable=all ../../SARD/C >& cppcheck_1.87_inc_out.out
./cppcheck-1.87/cppcheck_1.87_inc_out.out :E/W Total: 11592 Error: 7755 Warning: 3837 Perf: 297 Style: 143464
Checking 3 of the addons for cppcheck 1.87 found the following
find ./ -name "*.dump" | xargs -n 1 -P 1 /opt/rh/rh-python36/root/usr/bin/python3.6 /users/jborland/Projects/CPPCheck/cppcheck-1.87/addons/threadsafety.py >& ~/threadCheck_out.out
Thread
72 (warning): Local static object: badLock [threadsafety]
400 (warning): Local static object: dataBuffer [threadsafety]
132 (warning): Local static object: goodLock [threadsafety]
2 (warning): Local static object: HelperClass [threadsafety]
4 (warning): Local static variable: charString [threadsafety]
1200 (warning): Local static variable: dataBuffer [threadsafety]
Cert
1460 (style): Attempt to cast away const [cert-EXP05-C]
36 (style): Bitwise operator is used with a Boolean-like operand [cert-EXP46-c]
3025 (style): Do not use the rand() function for generating pseudorandom numbers [cert-MSC30-c]
224 (style): Ensure that integer conversions do not result in lost or misinterpreted data (casting -1 to unsigned long) [cert-INT31-c]
36 (style): Ensure that integer conversions do not result in lost or misinterpreted data (casting 4194304 to signed char) [cert-INT31-c]
MISRA Just a warning the misra check took 3 or 4 hours and generated 14Gigs of data. If you have lots of cores you could get the time down my check was single threaded just because
18 [misra-c2012-16.3]
18 [misra-c2012-7.1]
36 [misra-c2012-11.4]
66 [misra-c2012-11.9]
72 [misra-c2012-21.5]
102 [misra-c2012-16.6]
108 [misra-c2012-10.1]
138 [misra-c2012-16.4]
348 [misra-c2012-15.6]
410 [misra-c2012-21.10]
514 [misra-c2012-10.8]
580 [misra-c2012-3.1]
663 [misra-c2012-4.1]
756 [misra-c2012-13.4]
906 [misra-c2012-20.13]
1146 [misra-c2012-15.5]
1356 [misra-c2012-11.3]
1460 [misra-c2012-11.8]
2665 [misra-c2012-20.1]
3268 [misra-c2012-11.5]
3695 [misra-c2012-15.7]
6316 [misra-c2012-5.1]
9666 [misra-c2012-19.2]
12032 [misra-c2012-15.1]
15216 [misra-c2012-17.8]
16008 [misra-c2012-12.3]
23404 [misra-c2012-21.7]
33400 [misra-c2012-18.8]
37422 [misra-c2012-17.1]
98967 [misra-c2012-21.8]
111229 [misra-c2012-21.3]
118119 [misra-c2012-12.1]
122987 [misra-c2012-21.6]
191604 [misra-c2012-5.4]
208601 [misra-c2012-5.3]
217437 [misra-c2012-14.4]
411537 [misra-c2012-10.4]
95717279 [misra-c2012-5.2]