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

Or do what Markus said (sorry, slow at catching up with the e-mails
today :). 

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Schaefer, Doug
Sent: Wednesday, April 22, 2009 12:55 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Static Analysis Framework for CDT

The cdt-other component is not really intended for new bugs except when
people don't know what component to put them in. There is usually no
traffic there so I don't think it's worth creating an inbox for it.

I guess the bigger question is where do you want these things to go.
Should they go in cdt-core? Should we create a new component? I think
I'm for using cdt-core for now and as you get momentum we can create a
new component. But I'm open to what ever is easier for you.

Doug.

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

Doug, bugs in cdt-other component get assigned right to you, can we make
cdt-other-inbox so I can watch them?

Elmenthaler, Jens wrote:
> Done so:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=273251
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=273252
> 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]

> On Behalf Of Elena Laskavaia
> Sent: Wednesday, April 22, 2009 15:37
> To: CDT General developers list.
> Subject: 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
> _______________________________________________
> 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