Experimental Physics and
Industrial Control System

Dear all,

 

I spent the first day of the EPICS codeathon 2020 analyzing and pruning the settings in Codacy to try to improve the signal-to-noise ratio in the output from the static code analysis. I started out from the project that Ralph Lange had created before the Codeathon. Current issue list can be found here: https://app.codacy.com/gh/epics-base/epics-base/issues/index?bid=16430872

 

I will summarize my findings below, and I would be very grateful for any comments and/or suggestions:

 

Repository: epics-base (submodules not automatically parsed)

 

Total issues (initial default configuration): 1068

 

Breakdown by language:

C 742

C++ 202

Markdown 111

Shell 13

 

Breakdown by category:

Code style 619

Error prone 84

Security 365

 

Breakdown by level

Info 867

Warning 117

Error 24 <- Interesting

 

For C/C++ analysis two set of code patterns are used for the analysis:

1) Flawfinder

2) cppchecker

 

Steps to improve signal to noise ratio:

1) Flawfinder is reporting all use of standard string functions (e.g. strncpy) as Security issues of Info severity. We probably want to be able to use standard string functions. Removing the rules for this reduced the number of security issues by 331.

Total after: 737

 

2) Markdown syntax checker may find issues in the markdown documentation, but this is probably not the issues we are looking for. Removing the patterns for markdown removes 111 issues.

Total: 626

 

3) cppchecker generates a Security issue of Info level whenever it detects that the scope of any variable could be smaller than it actually is. This is not expected to generate any functional impact. Removing this rule removes 215 issues.

Total: 411

 

4) Flawfinder generates a Security issue of Info severity every time you copy something into a buffer in a loop, even when the buffer is a single character (such as when reading an input stream). Removing these patterns removes 56 issues.

Total: 355

 

5) cppcheck is not always able to resolve macros and environment variables. When it cannot run another check due to not being able to resolve a macro or environment variable it generates a Code Style issue of Info severity. Removing this rule clears another 42 issues.

Total: 313

 

6) The test code generates a fair number of issues. This is to be expected since test code generally does things that normally would seems nonsensical. Ignoring the test code folders removed an additional 54 issues.

Total: 259

 

In the analysis 24 issues are identified by the tool as "Errors" (highest level). These fall into a few categories:

 

- Memory leaks. This is typically due to missing free statements before returning in error cases. Likely to have limited or no impact, but very easy to fix.

 

- Possible null pointer dereferencing. In a handful of instances pointers are dereferenced without NULL check. The pointer should not be NULL, so practical impact is probably low. But correcting is again very easy.

 

- Uninitialized variables or struct fields. Occurs in a few places. Should probably be fixed.

 

- Potential memory leak in case of realloc failing. If realloc fails the original memory still needs to be freed. Since realloc rarely fails this probably has very low practical impact.

 

- cppchecker generates an Error severity issue whenever a #include statement does not include a header file. The modules/libcom/vxWorks/boost/config.hpp file declares a handful of includes using macros. I have not dug further into the issues, but I think they can safely be ignored. But since the issue is "Error" level I would like some feedback on this before I just ignore the issue.

 

- The startup/unix.sh does not include a shebang, hence the tools cannot determine if it works. I think this is "working as desiged" and should be ignored. But since the issue is "Error" level I would like some feedback on this before I just ignore the issue.

 

- A single instance of incorrect number of parameters for printf format string. Should just be fixed, looks like a simple mistake.

 

Some areas where I would like input:

 

1)      Is this time well spent?

2)      Do you agree with my analysis of the Error level issues above?

3)      If this is a tool we want to pursue, how to manage the configuration? Codacy does support configuration files that can be stored in the root of the source repository, but I have yet to dig into the formatting of such files. Excluding files and directories can certainly be managed, but I am less certain about the configuration of the analysis itself (such as ignoring specific rules).

4)      Finally, if we do decide to pursue this tool how do we visualize and use the results?

 

Best regards

 

Karl Vestin

Group Leader Hardware and Integration

Integrated Control Systems Division

European Spallation Source ERIC

 

+46721792066

P.O Box 176, SE 221 00 Lund, Sweden

Visiting address: Odarslövsvägen 113, Lund