[Gluster-devel] Proposal: Using LLVM clang-analyzer in gluster development

[Atin Mukherjee]

On 05/27/2015 12:24 AM, Niels de Vos wrote:
> On Tue, May 26, 2015 at 11:00:25PM +0530, Atin Mukherjee wrote:
>> On 26 May 2015 17:30, "Prasanna Kalever" <pkalever at redhat.com> wrote:
>>>
>>> Hi gluster team,
>>>
>>> Proposal:
>>>
>>> Using Clang static analyzer tool for gluster project
>>>
>>>
>>> About Clang:
>>>
>>> From a very high level view, Clang has two features
>>>
>>> 1. Clang as a compiler
>>> 2. Clang as a code analyzer
>>>
>>> The Idea hear is to use second point i.e Clang as code analyzer and still
>> gcc
>>> will be our default compiler.
>>>
>>> The Clang Static Analyzer is a source code analysis tool that finds bugs
>> in C,
>>> C++, and Objective-C programs. Given the exact same code base,
>> clang-analyzer
>>> reported ~70 potential issues. clang is an awesome and free tool.
>>>
>>> The reports from clang-analyzer are in HTML and there's a single file for
>> each
>>> issue and it generates a nice looking source code with embedded comments
>> about
>>> which flow that was followed all the way down to the problem.
>>>
>>>
>>> Why Clang-Analyzer: (Advantages)
>>>
>>>  1. Since its is an open source tool:
>>>
>>>   * Available to all the developers
>>>   * Easy Access, we can run the tool while we compile the code (say $
>> scan-build make)
>>>   * No restrictions on Number of Runs per week/day/hour/min ..
>>>   * Defects are Identified before submitting a patch, thus very less
>> chance of
>>>     defect injection into project
>>>
>>>  2. The Html view of clang is very impressive with all the source code
>> including
>>>     comments of clang-analyzer, which lead to defect line number directly
>> .
>>>
>>>
>>>
>>> I have attached a sample clang results for geo-replication module run on
>> latest
>>> 3.7+ glusterfs code, please find them above.
>>>
>>>
>>> Thanks for your time.
>> On a relative note, I feel we should try to integrate any of these static
>> analyzer as part of our checkpatch.pl and compare the pre and post report
>> and proceed if the change doesn't introduce any new defects. Thoughts?
> 
> That sounds more like a test we can run in Jenkins. Having this check in
> checkpatch.pl might be difficult because that should be able to run on
> any OS/distribution we support. When we move the test to Jenkins, we can
> run it on the regression test slaves and have them post -1 verified in
> case of issues.
Sounds good to me, be it at local or jenkins, my only intention is to
refrain introducing defects for a new patch.
> 
> Are there tools to do the pre/post result comparing? I have recently
> setup a test environment for Jenkins jobs and am happy to give you (or
> any one else) access to it for testing (sorry, my setup is on the Red
> Hat internal network only).
We need to explore on that part, I am hoping that we should have such
kind of tools available. However if not at worst case can't we compare
them through our own scripts?
> 
> Niels
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 

-- 
~Atin