[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