Re: Coverity Scan for GNUstep?

2018-01-29 Thread Fred Kiefer


> Am 29.01.2018 um 20:33 schrieb Wolfgang Lux :
> 
> 
> 
>> Am 29.01.2018 um 18:15 schrieb Fred Kiefer :
>> 
>> 
>> 
>>> Am 29.01.2018 um 11:32 schrieb Richard Frith-Macdonald 
>>> :
>>> 
 On 29 Jan 2018, at 08:28, Fred Kiefer  wrote:
 
 re is a problem with these numbers. Coverity did only analyse about one 
 third of the Objective-C files in GNUstep base and most likely only the 
 smaller files. Coverity at the moment has issues with Objective-C 
 protocols and only works with files where there are no references to any. 
 That means we don’t know how many of the 1 million lines where actually 
 checked for defects. The number 0.01 is basically meaningless :-)
>>> 
>>> :-(
>>> 
>>> Where do I look to find out about thi
>>> I don't think gnustep-base actually *uses* protocols much, so perhaps we 
>>> can figure out ways to work around this limitation?
>> 
>> When running Coverity it reports these numbers (I would like to paste the 
>> messages here, but copy/paste is not working in my virtual machine :-(
>> It says that 54 Objective-C (27%) files where „emitted“ and 93 (36%) are 
>> ready for analysis.
>> 
>> As for the protocols, this is just how I translate this message from 
>> Coverity:
>> 
>> cov-internal-emit-clang-main.cpp:5: assertion failure: 
>> xlate-ast-types.cpp:1807: assertion failed: ObjCTypeParamType translation 
>> not implemented.
>> 
>> If you look at the clang code you see that  ObjCTypeParamType was introduced 
>> to support protocols.
> 
> I think that is a misunderstanding. ObjCTypeParamType is the syntactic 
> category related to type parameters of generic types. For instance, given a 
> declaration
>  NSArray *array;
> ElemType is the type parameter here and it signals that the array should 
> contain only instances of ElemType.

Thank you Wolfgang,

that was the idea that I needed to get further. I disabled the GS_GENERIC_CLASS 
macro in NSObjCRuntime.h and now all the files seem to compile with Coverity. 
The new result is currently being uploaded and will hopefully be processed in 
the next few hours. With that we should have a better picture of our „defect 
rate"

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Coverity Scan for GNUstep?

2018-01-29 Thread Wolfgang Lux


> Am 29.01.2018 um 18:15 schrieb Fred Kiefer :
> 
> 
> 
>> Am 29.01.2018 um 11:32 schrieb Richard Frith-Macdonald 
>> :
>> 
>>> On 29 Jan 2018, at 08:28, Fred Kiefer  wrote:
>>> 
>>> re is a problem with these numbers. Coverity did only analyse about one 
>>> third of the Objective-C files in GNUstep base and most likely only the 
>>> smaller files. Coverity at the moment has issues with Objective-C protocols 
>>> and only works with files where there are no references to any. That means 
>>> we don’t know how many of the 1 million lines where actually checked for 
>>> defects. The number 0.01 is basically meaningless :-)
>> 
>> :-(
>> 
>> Where do I look to find out about this?
>> I don't think gnustep-base actually *uses* protocols much, so perhaps we can 
>> figure out ways to work around this limitation?
> 
> When running Coverity it reports these numbers (I would like to paste the 
> messages here, but copy/paste is not working in my virtual machine :-(
> It says that 54 Objective-C (27%) files where „emitted“ and 93 (36%) are 
> ready for analysis.
> 
> As for the protocols, this is just how I translate this message from Coverity:
> 
> cov-internal-emit-clang-main.cpp:5: assertion failure: 
> xlate-ast-types.cpp:1807: assertion failed: ObjCTypeParamType translation not 
> implemented.
> 
> If you look at the clang code you see that  ObjCTypeParamType was introduced 
> to support protocols.

I think that is a misunderstanding. ObjCTypeParamType is the syntactic category 
related to type parameters of generic types. For instance, given a declaration
  NSArray *array;
ElemType is the type parameter here and it signals that the array should 
contain only instances of ElemType.

Wolfgang


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Coverity Scan for GNUstep?

2018-01-29 Thread Fred Kiefer


> Am 29.01.2018 um 11:32 schrieb Richard Frith-Macdonald 
> :
> 
>> On 29 Jan 2018, at 08:28, Fred Kiefer  wrote:
>> 
>> re is a problem with these numbers. Coverity did only analyse about one 
>> third of the Objective-C files in GNUstep base and most likely only the 
>> smaller files. Coverity at the moment has issues with Objective-C protocols 
>> and only works with files where there are no references to any. That means 
>> we don’t know how many of the 1 million lines where actually checked for 
>> defects. The number 0.01 is basically meaningless :-)
> 
> :-(
> 
> Where do I look to find out about this?
> I don't think gnustep-base actually *uses* protocols much, so perhaps we can 
> figure out ways to work around this limitation?

When running Coverity it reports these numbers (I would like to paste the 
messages here, but copy/paste is not working in my virtual machine :-(
It says that 54 Objective-C (27%) files where „emitted“ and 93 (36%) are ready 
for analysis.

As for the protocols, this is just how I translate this message from Coverity:

cov-internal-emit-clang-main.cpp:5: assertion failure: 
xlate-ast-types.cpp:1807: assertion failed: ObjCTypeParamType translation not 
implemented.

If you look at the clang code you see that  ObjCTypeParamType was introduced to 
support protocols. I asked David for some explanations here up to now with any 
reply.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Coverity Scan for GNUstep?

2018-01-29 Thread Ivan Vučica
On Mon, Jan 29, 2018 at 10:32 AM, Richard Frith-Macdonald
 wrote:
>> On 29 Jan 2018, at 08:28, Fred Kiefer  wrote:
>>
>> re is a problem with these numbers. Coverity did only analyse about one 
>> third of the Objective-C files in GNUstep base and most likely only the 
>> smaller files. Coverity at the moment has issues with Objective-C protocols 
>> and only works with files where there are no references to any. That means 
>> we don’t know how many of the 1 million lines where actually checked for 
>> defects. The number 0.01 is basically meaningless :-)
>
> :-(
>
> Where do I look to find out about this?
> I don't think gnustep-base actually *uses* protocols much, so perhaps we can 
> figure out ways to work around this limitation?

Also sounds like it wouldn't be very useful with OS X code unless all
headers and code were stripped of protocols before processing with Coverity.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Coverity Scan for GNUstep?

2018-01-29 Thread Richard Frith-Macdonald


> On 29 Jan 2018, at 08:28, Fred Kiefer  wrote:
> 
> re is a problem with these numbers. Coverity did only analyse about one third 
> of the Objective-C files in GNUstep base and most likely only the smaller 
> files. Coverity at the moment has issues with Objective-C protocols and only 
> works with files where there are no references to any. That means we don’t 
> know how many of the 1 million lines where actually checked for defects. The 
> number 0.01 is basically meaningless :-)

:-(

Where do I look to find out about this?
I don't think gnustep-base actually *uses* protocols much, so perhaps we can 
figure out ways to work around this limitation?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Coverity Scan for GNUstep?

2018-01-29 Thread Fred Kiefer


> Am 29.01.2018 um 09:20 schrieb Richard Frith-Macdonald 
> :
> 
> 
> 
>> On 22 Jan 2018, at 22:23, Fred Kiefer  wrote:
>> 
>> 
>> In the meantime my connection with GNUstep has been confirmed and I was able 
>> to look at the found issues. Many of them are false positives mostly caused 
>> by Coverity expecting normal program continuation after NSException raise. 
>> Even so it did detect a few potential issues in base. I flagged some of the 
>> false positives so the more interesting bits are left over for somebody to 
>> look at. Especially the „time of check, time of use“ issues should be looked 
>> at. 
> 
> I think the few outstanding defects are all addressed now,
> Looking at a link from the coverty report I found this:
> 
> Open Source Defect Density
> 
> GNUstep base: 999,026 line of code and 0.01 defect density
> 
> Open Source Defect Density By Project Size
> 
> Line of Code (LOC)Defect Density
> Less than 100,000 0.35
> 100,000 to 499,9990.5
> 500,000 to 1 million  0.7
> More than 1 million   0.65
> Note: Defect density is measured by the number of defects per 1,000 lines of 
> code, identified by the Coverity platform. The numbers shown above are from 
> our 2013 Coverity Scan Report, which analyzed 250 million lines of open 
> source code.
> 
> While it would have been better if it hadn't found any defects, it's still 
> nice to see that our defect density is about a 70th of their normal finding 
> (presumably those ratings are mean values for projects in the four size 
> categories).

There is a problem with these numbers. Coverity did only analyse about one 
third of the Objective-C files in GNUstep base and most likely only the smaller 
files. Coverity at the moment has issues with Objective-C protocols and only 
works with files where there are no references to any. That means we don’t know 
how many of the 1 million lines where actually checked for defects. The number 
0.01 is basically meaningless :-)

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Coverity Scan for GNUstep?

2018-01-29 Thread Richard Frith-Macdonald


> On 22 Jan 2018, at 22:23, Fred Kiefer  wrote:
> 
> 
> In the meantime my connection with GNUstep has been confirmed and I was able 
> to look at the found issues. Many of them are false positives mostly caused 
> by Coverity expecting normal program continuation after NSException raise. 
> Even so it did detect a few potential issues in base. I flagged some of the 
> false positives so the more interesting bits are left over for somebody to 
> look at. Especially the „time of check, time of use“ issues should be looked 
> at. 

I think the few outstanding defects are all addressed now,
Looking at a link from the coverty report I found this:

Open Source Defect Density

GNUstep base: 999,026 line of code and 0.01 defect density

Open Source Defect Density By Project Size

Line of Code (LOC)  Defect Density
Less than 100,000   0.35
100,000 to 499,999  0.5
500,000 to 1 million0.7
More than 1 million 0.65
Note: Defect density is measured by the number of defects per 1,000 lines of 
code, identified by the Coverity platform. The numbers shown above are from our 
2013 Coverity Scan Report, which analyzed 250 million lines of open source code.

While it would have been better if it hadn't found any defects, it's still nice 
to see that our defect density is about a 70th of their normal finding 
(presumably those ratings are mean values for projects in the four size 
categories).
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev