[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Static Analysis Framework for CDT
|
You can also use the cdt-source-nav component. The name is not great
however it is meant to be used for the parser/indexer based tools.
Markus.
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia
> Sent: Wednesday, April 22, 2009 4:09 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Static Analysis Framework for CDT
> Importance: Low
>
> 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
>
