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@xxxxxxxxxx> 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@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel > -- ~Atin _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
