[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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