[
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
