Dear all,
After some back-and-forth with the Codacy support team I have now enabled static code analysis for both epics-base and the associated submodules. The pattern configuration and exclusion of files is based on configuration from the codeathon.
Currently enabled checkers:
cppcheck (200 active patterns. This checker finds by far the most issues)
flawfinder (13 active patterns)
shellcheck (22 active patterns)
Please note that as long as we keep using the web UI to maintain the configuration it is not possible to share configuration between the repositories. If we were to move to using configuration files we could use one set of files however.
I have cloned the setup for the repositories, so they are identical now.
The current status of issues is:
Module
|
Information
|
Warning
|
Error
|
pvDatabaseCPP
|
6
|
8
|
0
|
pvAccessCPP
|
51
|
48
|
2
|
epics-base
|
128
|
18
|
7
|
pva2pva
|
11
|
3
|
0
|
pvDataCPP
|
10
|
0
|
2
|
pvClientCPP
|
2
|
0
|
0
|
normativeTypesCPP*
|
0
|
0
|
0
|
* I don’t think this is correct. Have raised the issue with Codacy support.
How to continue: I think the best way to proceed with static code analysis is to use it primarily as an additional tool for reviewing pull requests. It is a good way to avoid new releases introducing memory leaks or similar. Regarding the
existing issues I think a reasonable ambition would be to remove the “Error” level issues and at some point at least have a look at the “Warning” level issues.
I hope this contribution has been somewhat useful. I am happy to answer further questions and/or analyze specific issues, but due to other commitments my available time is quite limited.
Best regards
Karl Vestin