Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Static Analysis Framework for CDT 
Can you please send both of them as cdt bugs into cdt-other component with prefix [code analysis]. It would be easier to track than on forum.

Elmenthaler, Jens wrote:

How about another checker (I just ran into it;-)

A variable declaration masking another variable declaration of a parent scope:

Void function()
{
  Int var = 0;

  {
    Guard<Mutex> guard(mMutex);

    Int var = 0; // ERROR: ...
  }
}
Jens. 
-----Original Message-----
From: Elmenthaler, Jens Sent: Wednesday, April 22, 2009 09:12 
To: 'CDT General developers list.'
Subject: RE: [cdt-dev] Static Analysis Framework for CDT

Hi Elena,

just another idea for a checker: class has virtual methods but non-virtual destructor

Jens.

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia
Sent: Monday, April 20, 2009 22:30
To: CDT General developers list.
Subject: Re: [cdt-dev] Static Analysis Framework for CDT

There are some reasons why it is not the same:
1) It is tend to be a LOT more checkers for C/C++ including style checking, metrics checkers, problems, security, etc, because of that
flat category hierarchy is not enough it has to be a tree
2) I could have done Error, Warning, Ignore but with more checkers it is easier to use checkboxes to check on/off whole category when do one by one (and it would remember previous severity).

Mike Kucera wrote:
We can steal ideas for checkers from the Java compiler Errors/Warnings preference page. Also, maybe the CDT code analysis preferences page should look the same, for a more consistent UI. 

Mike Kucera
Software Developer
IBM Eclipse CDT Team
mkucera@xxxxxxxxxx
Inactive hide details for Elena Laskavaia ---04/20/2009 10:51:24 AM---There is not much of this "framework" can be re-used for Elena Laskavaia ---04/20/2009 10:51:24 AM---There is not much of this "framework" can be re-used for self contained external tool like that. 


From:	
Elena Laskavaia <elaskavaia@xxxxxxx>

To:	
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

Date:	
04/20/2009 10:51 AM

Subject:	
Re: [cdt-dev] Static Analysis Framework for CDT

------------------------------------------------------------------------
There is not much of this "framework" can be re-used for self contained external tool like that. I don't think even error parser is required because it would just work with gcc error parser, so it would pretty much work out of box considering integration is provided by makefile (which should be done anyway on make/build level and not invoked externally)
Btw, I am pretty much done with preliminary framework (without data-flow graphs etc), I update wiki page 
http://wiki.eclipse.org/CDT/designs/StaticAnalysis
added screenshots for user interface, comments are welcome.
I have 2 checkers now Assignment in Condition from Markus presentation and Statement has no Effect. Checkers contributions are welcome. We need at least dozen checkers to make it worthy to include as feature in next CDT. 

Schaefer, Doug wrote:
 > That sounds reasonable. I'm still concerned about the licensing issues
 > with the GCC plug-in framework, but we're starting to figure out how to
 > manage that with the packaging efforts.
 >
 > Cheers,
 > Doug.
 >
 >> -----Original Message-----
 >> From: cdt-dev-bounces@xxxxxxxxxxx
 >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Dominique Toupin
 >> Sent: Monday, April 20, 2009 7:47 AM
 >> To: CDT General developers list.
 >> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
 >>
 >>
 >> This is indeed the best setup, everything we can check
 >> rapidly we can do it inside CDT even before the code is build.
 >> Then the complicated/longer analysis are done by external
 >> tools, some of those analysis are running at night.
 >> What I was pointing out below is we might be able to use GCC
 >> plugins for complicated/long analysis, we would then have a
 >> complete static analysis framework in CDT.
 >>
 >> "If you are doing simple rules, CDT alone should be OK but if
 >> you need complicated rules (e.g. data-flow analysis) then you
 >> might want to also look at GCC plugin"
 >>
 >>
 >>
 >>> -----Original Message-----
 >>> From: cdt-dev-bounces@xxxxxxxxxxx
 >>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
 >>> Sent: 20-Apr-09 04:03
 >>> To: CDT General developers list.
 >>> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
 >>>
 >>> I don't have plans to work on something like that. However, I think
 >>> there is lots of value we could add to CDT by doing some
 >> analysis on
 >>> the parser side. This is not because we can do better analysis than
 >>> gcc or other tools, it is because we could do some analyis much
 >>> earlier, when you edit your code and could ideally also provide
 >>> quick-fixes. The most simple example is the detection of
 >> assignments
 >>> in conditions 'if (a = 0)', which is easy to detect and
 >> easy to fix.
 >>> CDT should offer support for that.
 >>>
 >>> Markus.
 >>>
 >>>> -----Original Message-----
 >>>> From: cdt-dev-bounces@xxxxxxxxxxx
 >>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Dominique Toupin
 >>>> Sent: Friday, April 17, 2009 6:08 PM
 >>>> To: CDT General developers list.
 >>>> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
 >>>> Importance: Low
 >>>>
 >>>>
 >>>> Markus, are you planning on providing advanced static
 >> analysis e.g.
 >>>> data-flow analysis :-)
 >>>>
 >>>>> -----Original Message-----
 >>>>> From: cdt-dev-bounces@xxxxxxxxxxx
 >>>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
 >>>>> Sent: 17-Apr-09 11:53
 >>>>> To: CDT General developers list.
 >>>>> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
 >>>>>
 >>>>> Then I suggest that you need to take a closer look at the
 >>>> CDT core ;)
 >>>>> Markus's EclipseCon presentation would be a great place
 >> to start.
 >>>>> Doug.
 >>>>>
 >>>>> On Fri, 2009-04-17 at 11:21 -0400, Dominique Toupin wrote:
 >>>>>> In practice I don't think CDT parser has the same
 >>>>> info/capability as
 >>>>>> GCC, GCC has a lot of info about the code and we can do
 >>>>> advance static
 >>>>>> analysis (not grep like) with this info.
 >>>>>> I am not suggesting to integrate GCC code into CDT, the
 >>>> GCC static
 >>>>>> analysis would be an external tool just like GCC/GDB today.
 >>>>>> Even if it's an external tool it brings a lot of features
 >>>>> to CDT, it's
 >>>>>> just like compile (GCC) and debug (GDB) today.
 >>>>>>
 >>>>>>> -----Original Message-----
 >>>>>>> From: cdt-dev-bounces@xxxxxxxxxxx
 >>>>>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
 >>> Doug Schaefer
 >>>>>>> Sent: 17-Apr-09 09:52
 >>>>>>> To: CDT General developers list.
 >>>>>>> Subject: Re: [cdt-dev] Static Analysis Framework for CDT
 >>>>>>>
 >>>>>>> My bigger concern is that all GCC plug-ins must be GPL. I'd
 >>>>>>> especially be worried about plug-ins written
 >>>> specifically for the
 >>>>>>> CDT and whether that affects the definition of "derived"
 >>>>>>> and thus, causing us legal grief.
 >>>>>>>
 >>>>>>> At any rate, theoretically, the CDT parsers already
 >>>>> create the same
 >>>>>>> information that gcc would. And we can avoid any legal
 >>>>> problems that
 >>>>>>> way.
 >>>>>>>
 >>>>>>> Doug.
 >>>>>>>
 >>>>>>> On Fri, 2009-04-17 at 09:43 -0400, Elena Laskavaia wrote:
 >>>>>>>> GCC plugins means it would be part of GCC which
 >> is external
 >>>>>>> to eclipse?
 >>>>>>>> If so it can be just run as external and not part of the
 >>>>>>> framework which is Java based.
 >>>>>>>> Dominique Toupin wrote:
 >>>>>>>>> Hi Elena,
 >>>>>>>>>
 >>>>>>>>> If you are doing simple rules, CDT alone should be OK
 >>>>> but if you
 >>>>>>>>> need complicated rules (e.g. data-flow
 >> analysis) then you
 >>>>>>> might want
 >>>>>>>>> to also look at GCC plugin
 >>>>>>> http://gcc.gnu.org/wiki/GCC_Plugins, they
 >>>>>>>>> did progress and hopefully the architecture will be
 >>>>>>> resolve for the
 >>>>>>>>> GCC summit (http://gccsummit.org/2009/), some CDT
 >>>> committers
 >>>>>>>>> will also attend the GCC summit (at least Francois
 >>>> and Marc).
 >>>>>>>>> Last year at the GCC summit some static analysis tools
 >>>>>>> based on GCC
 >>>>>>>>> where presented e.g.
 >>>>> https://developer.mozilla.org/en/Treehydra,
 >>> https://developer.mozilla.org/en/Dehydra?rdfrom=https%3A%2F%2Fwiki.m
 >>>>>>>>> ozil
 >>>> la.org%2Findex.php%3Ftitle%3DDehydra_GCC%26redirect%3Dno.
 >>>>>>>>> If we can have good static analysis rules with GCC
 >>>>>>> plugins it will
 >>>>>>>>> make sense to integrate those into CDT.
 >>>>>>>>>
 >>>>>>>>> Dominique
 >>>>>>>>>
 >>>>>>>>>
 >>>>>>>>>> -----Original Message-----
 >>>>>>>>>> From: cdt-dev-bounces@xxxxxxxxxxx
 >>>>>>>>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
 >> Of Elena
 >>>>>>>>>> Laskavaia
 >>>>>>>>>> Sent: 16-Apr-09 22:44
 >>>>>>>>>> To: CDT General developers list.
 >>>>>>>>>> Subject: [cdt-dev] Static Analysis Framework for CDT
 >>>>>>>>>>
 >>>>>>>>>> This is something I am doing in my spare time -
 >>> I want to
 >>>>>>>>>> create static analysis framework for CDT, light
 >>>> weigh set of
 >>>>>>> classes that
 >>>>>>>>>> allow to have common interface for dealing
 >> with problems
 >>>>>>> produced
 >>>>>>>>>> by static analysis tools (and some default checkers,
 >>>>>>> such what JDT
 >>>>>>>>>> has, i.e Potential Null Pointer Dereference, etc).
 >>>>>>>>>>
 >>>>>>>>>> See design details at:
 >>>>>>>>>> http://wiki.eclipse.org/CDT/designs/StaticAnalysis
 >>>>>>>>>> _______________________________________________
 >>>>>>>>>> cdt-dev mailing list
 >>>>>>>>>> cdt-dev@xxxxxxxxxxx
 >>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>>>>>>>>
 >>>>>>>>> _______________________________________________
 >>>>>>>>> cdt-dev mailing list
 >>>>>>>>> cdt-dev@xxxxxxxxxxx
 >>>>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>>>>>> _______________________________________________
 >>>>>>>> cdt-dev mailing list
 >>>>>>>> cdt-dev@xxxxxxxxxxx
 >>>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>>>>> _______________________________________________
 >>>>>>> cdt-dev mailing list
 >>>>>>> cdt-dev@xxxxxxxxxxx
 >>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>>>>>
 >>>>>> _______________________________________________
 >>>>>> cdt-dev mailing list
 >>>>>> cdt-dev@xxxxxxxxxxx
 >>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>>> _______________________________________________
 >>>>> cdt-dev mailing list
 >>>>> cdt-dev@xxxxxxxxxxx
 >>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>>>
 >>>> _______________________________________________
 >>>> cdt-dev mailing list
 >>>> cdt-dev@xxxxxxxxxxx
 >>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>>
 >>> _______________________________________________
 >>> cdt-dev mailing list
 >>> cdt-dev@xxxxxxxxxxx
 >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>>
 >> _______________________________________________
 >> cdt-dev mailing list
 >> cdt-dev@xxxxxxxxxxx
 >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
 >>
 > _______________________________________________
 > cdt-dev mailing list
 > cdt-dev@xxxxxxxxxxx
 > https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



------------------------------------------------------------------------

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top