[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Static Analysis Framework for CDT
|
Ok. Let it be cdt-source-nav
Schaefer, Doug wrote:
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev