[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Static Analysis Framework for CDT
|
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
