Re: Coverity Scan for GNUstep?

[Richard Frith-Macdonald]

> On 9 Feb 2018, at 07:43, Fred Kiefer  wrote:
> 
> Just to keep you updated. Due to Richard’s work over the last few weeks we 
> are now down to zero open issues on Coverity. (They display that there still 
> is one, but in the details they don’t display any open ones. Maybe the web 
> interface cannot cope with zero?) This is an excellent result and shows how 
> well written base was even before the analysis started.
> It would be great if someone besides me and Richard would be willing to 
> recheck all the issues we marked as false positives or intentional. Just to 
> make sure we didn’t hide anything important there.

Thanks for being the person to push all this forward Fred.  Without your 
willingness to set up the Coverity project and generate the data to feed it, 
this wouldn't have happened.

I think I have fixed the final issue (had to play with the filter settings in 
the CoverityGUI to see it), which was a potential buffer overrun if someone 
tampers with the timezone data files on the system (a very minor risk, since 
timezone data is normally installed read-only and owned by root, but still a 
real one).

> I will be away from my computer for the next two weeks so either no scans 
> during that period or somebody else will have to do it. We could now start to 
> discuss whether setting up scans for other parts of GNUstep would be 
> worthwhile and maybe even test how to integrate Coverity into Travis on 
> GitHub.

I hope to find time to set up my system to do coverity builds/scans this 
weekend.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

Just to keep you updated. Due to Richard’s work over the last few weeks we are 
now down to zero open issues on Coverity. (They display that there still is 
one, but in the details they don’t display any open ones. Maybe the web 
interface cannot cope with zero?) This is an excellent result and shows how 
well written base was even before the analysis started.
It would be great if someone besides me and Richard would be willing to recheck 
all the issues we marked as false positives or intentional. Just to make sure 
we didn’t hide anything important there.

I will be away from my computer for the next two weeks so either no scans 
during that period or somebody else will have to do it. We could now start to 
discuss whether setting up scans for other parts of GNUstep would be worthwhile 
and maybe even test how to integrate Coverity into Travis on GitHub.

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

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

I just uploaded yet another scan, even though Richard is already in the process 
of fixing the issues of the last one. 

It looks like Coverity is ignoring the compiler annotations in [NSException 
raise]. To work around this I added a Coverity specific annotation in my local 
file („// covertly[+kill]„) to see if this improves the results. Currently our 
defect density is 0.16 and this is already an excellent number, even though 
there are a lot of false positives.

> Am 29.01.2018 um 23:41 schrieb Fred Kiefer :
> 
> 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"


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

Re: Coverity Scan for GNUstep?

[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?

[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?

[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?

[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?

[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?

[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?

[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

Re: Coverity Scan for GNUstep?

[David Chisnall]

On 24 Jan 2018, at 23:56, Ivan Vučica  wrote:
> 
> Even though it's just silencing this warning, I'm nonetheless creating
> a patch for gdomap.

It isn’t just silencing the warning, it’s also generating smaller code.  When 
calling a function that doesn’t return, the compiler doesn’t have to emit any 
code to handle the return path - no registers or stack slots are going to be 
live after the call and so it doesn’t have to bother saving anything.  It 
probably only saves 2-3 instructions at most call sites, but across a few 
hundred calling locations that can add up to a lot.

David


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

Re: Coverity Scan for GNUstep?

[Richard Frith-Macdonald]

> On 25 Jan 2018, at 07:41, Fred Kiefer  wrote:
> 
> 
> 
>> Am 25.01.2018 um 00:59 schrieb Ivan Vučica :
>> 
>> On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica  wrote:
>>> On Mon, Jan 22, 2018 at 10:23 PM, 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.
>>> 
>>> Some of this type of issues can be fixed with __attribute__ ((noreturn)).
>>> 
>>> Manual says "The attribute noreturn is not implemented in GCC versions
>>> earlier than 2.5." which is older than what we support, so it should
>>> be fine.
>>> 
>>> Even though it's just silencing this warning, I'm nonetheless creating
>>> a patch for gdomap.
>> 
>> Please disregard the mention of creating a patch for gdomap.c.
>> 
>> I've taken a closer look only a few seconds after posting this and it
>> looks like gdomap_log exits only sometimes, so the 'breaks are
>> missing' warning is probably correct.
>> 
>> I won't be creating the patch adding noreturn.
> 
> I was hoping you would provide such a patch for the NSException methods that 
> won’t return. That was the type of false positives that showed up the most in 
> the Coverity list.

I'm looking into that.


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

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

> Am 25.01.2018 um 00:59 schrieb Ivan Vučica :
> 
> On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica  wrote:
>> On Mon, Jan 22, 2018 at 10:23 PM, 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.
>> 
>> Some of this type of issues can be fixed with __attribute__ ((noreturn)).
>> 
>> Manual says "The attribute noreturn is not implemented in GCC versions
>> earlier than 2.5." which is older than what we support, so it should
>> be fine.
>> 
>> Even though it's just silencing this warning, I'm nonetheless creating
>> a patch for gdomap.
> 
> Please disregard the mention of creating a patch for gdomap.c.
> 
> I've taken a closer look only a few seconds after posting this and it
> looks like gdomap_log exits only sometimes, so the 'breaks are
> missing' warning is probably correct.
> 
> I won't be creating the patch adding noreturn.

I was hoping you would provide such a patch for the NSException methods that 
won’t return. That was the type of false positives that showed up the most in 
the Coverity list.


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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica  wrote:
> On Mon, Jan 22, 2018 at 10:23 PM, 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.
>
> Some of this type of issues can be fixed with __attribute__ ((noreturn)).
>
> Manual says "The attribute noreturn is not implemented in GCC versions
> earlier than 2.5." which is older than what we support, so it should
> be fine.
>
> Even though it's just silencing this warning, I'm nonetheless creating
> a patch for gdomap.

Please disregard the mention of creating a patch for gdomap.c.

I've taken a closer look only a few seconds after posting this and it
looks like gdomap_log exits only sometimes, so the 'breaks are
missing' warning is probably correct.

I won't be creating the patch adding noreturn.

>> 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.
>>
>> Fred
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

On Mon, Jan 22, 2018 at 10:23 PM, 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.

Some of this type of issues can be fixed with __attribute__ ((noreturn)).

Manual says "The attribute noreturn is not implemented in GCC versions
earlier than 2.5." which is older than what we support, so it should
be fine.

Even though it's just silencing this warning, I'm nonetheless creating
a patch for gdomap.

> 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.
>
> Fred
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

> Am 21.01.2018 um 11:30 schrieb Fred Kiefer :
> 
> Over this weekend I tried to set up Coverity for GNUstep base. I chose base 
> because it is the most widely used part of GNUstep.
> 
> The first thing I had to learn was that Coverity supports Objective-C but 
> only in connection with clang. This isn’t documented anywhere but becomes 
> obvious when you read through a few dozens of configuration files. So I had 
> to set up a clang only system for which I selected Ubuntu 17/10 on a 
> VirtualBox machine. For this setup I tried to follow the instructions on 
> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux and they are 
> clearly outdated and incorrect. The configuration of GNUstep make needs to 
> include „—with-library-combo=ng-gnu-gnu“ and during the compilation of 
> libobjc2 I had to use make instead of cmake. As I am no expert in this setup 
> I would prefer if somebody with a bit more experiences would correct this 
> wiki page. This really would help to save others the frustration I did get 
> from not even being able to set up the first few steps of GNUstep. 
> Compilation with gcc has been straight forward for more then 15 years now. We 
> should get clang/libobjc2 support onto the same level.
> 
> With that finally in place I was able to run the first Coverity analysis. 
> Sadly this could only process one third of your source files. For the rest I 
> did get error messages like this:
> 
> cov-internal-emit-clang-main.cpp:5: assertion failure: 
> xlate-ast-types.cpp:1807: assertion failed: ObjCTypeParamType translation not 
> implemented.
> 
> (I had to type this as copy/paste somehow won’t work from my VirtualBox)
> 
> I have no idea whether this is an issue in clang or Coverity or maybe I did 
> forget some required setup step. Just from the file names I would say it is 
> something Coverity left out when implementing Objective-C support. Maybe 
> switching to an older version of clang could help?
> 
> The actual scan result ends up in an Sqlite DB you have to upload it to 
> Coverity to get some readable information from it. The project is now at 
> https://scan.coverity.com/projects/gnustep-base and awaits validation. 
> Somebody at Coverity needs to check whether I am actually connected to the 
> project I would like to scan. But with most files being left out from the 
> analysis the results will be mostly meaningless anyway. I hope to be able to 
> see the results in a few days and report whether they look promising or not. 
> In the later case I will drop the whole project. Otherwise I would try to 
> reach Coverity and discuss the issue with somebody there.

 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. 

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

Re: Coverity Scan for GNUstep?

[David Chisnall]

On 21 Jan 2018, at 21:33, Fred Kiefer  wrote:
> 
> Oops, you are correct. I just rechecked my command history and it must have 
> been the second line „cmake —build .“ which caused me issues. I then checked 
> the INSTALL file of libobjc2 and followed the instructions from there, but 
> still needed the -DTESTS=OFF switch to finally get it working.

That’s a bit worrying, as it implies that the tests weren’t even building for 
you.  Travis is testing them on Linux and macOS and I’m running them manually 
on FreeBSD, and all of them exception the C++ exception interop (which is 
broken only on macOS) pass in all places.

David


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

Re: Coverity Scan for GNUstep?

[Patryk Laurent]

> On Jan 21, 2018, at 02:30, Fred Kiefer  wrote:
> 
> So I had to set up a clang only system for which I selected Ubuntu 17/10 on a 
> VirtualBox machine. For this setup I tried to follow the instructions on 
> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux and they are 
> clearly outdated and incorrect.

Hi Fred,

Thank you for trying the script on Ubuntu 17.10 and providing feedback. As far 
as I know you are the first to do so (the latest version of Ubuntu the wiki 
page refers to is 17.04).

I’ll look into integrating and testing out the improvements/corrections you’ve 
provided!

Regards,
Patryk


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

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

> Am 21.01.2018 um 22:19 schrieb Ivan Vučica :
> 
> 
> On Sun, Jan 21, 2018 at 9:12 PM Fred Kiefer  wrote:
> 
> 
> > Am 21.01.2018 um 22:04 schrieb Ivan Vučica :
> >
> > @fred:
> > I don't know why you had to use make without first generating makefiles 
> > with cmake.
> 
> Sorry, I was a bit unclear here. The wiki has three lines of cmake when 
> building libobjc2 and at least the last one (but I think the last two) need 
> to be make.
> Does this make more sense?
> 
> I see this:
> 
> cmake ../ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang 
> -DCMAKE_ASM_COMPILER=clang -DTESTS=OFF
> cmake --build .
> sudo -E make install

Oops, you are correct. I just rechecked my command history and it must have 
been the second line „cmake —build .“ which caused me issues. I then checked 
the INSTALL file of libobjc2 and followed the instructions from there, but 
still needed the -DTESTS=OFF switch to finally get it working.


> n.b. I usually use just "make" instead of "cmake --build ."; I was unaware 
> that --build is a thing.
>  
> 
> I also don’t know whether we need to install GNUstep make first, if we use 
> cmake for libobjc2. But this still might be the case.
> 
> I think -make and -base would prefer to see libobjc2 first.
> 
> libobjc2 does not require -make; I definitely install libobjc2 first, and 
> only once.

It would be great to have your simpler instructions in the wiki.



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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

On Sun, Jan 21, 2018 at 9:12 PM Fred Kiefer  wrote:

>
>
> > Am 21.01.2018 um 22:04 schrieb Ivan Vučica :
> >
> > @fred:
> > I don't know why you had to use make without first generating makefiles
> with cmake.
>
> Sorry, I was a bit unclear here. The wiki has three lines of cmake when
> building libobjc2 and at least the last one (but I think the last two) need
> to be make.
> Does this make more sense?
>

I see this:

cmake ../ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang
-DCMAKE_ASM_COMPILER=clang -DTESTS=OFF
cmake --build .
sudo -E make install

n.b. I usually use just "make" instead of "cmake --build ."; I was unaware
that --build is a thing.


>
> I also don’t know whether we need to install GNUstep make first, if we use
> cmake for libobjc2. But this still might be the case.
>

I think -make and -base would prefer to see libobjc2 first.

libobjc2 does not require -make; I definitely install libobjc2 first, and
only once.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

> Am 21.01.2018 um 22:04 schrieb Ivan Vučica :
> 
> @fred:
> I don't know why you had to use make without first generating makefiles with 
> cmake.

Sorry, I was a bit unclear here. The wiki has three lines of cmake when 
building libobjc2 and at least the last one (but I think the last two) need to 
be make.
Does this make more sense?

I also don’t know whether we need to install GNUstep make first, if we use 
cmake for libobjc2. But this still might be the case.

Fred


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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

@david:
-base and -gui do have Travis configured -- I just checked. back doesn't. I
have not looked at other projects.

@fred:
I don't know why you had to use make without first generating makefiles
with cmake.

On Sun, Jan 21, 2018 at 11:06 AM, David Chisnall  wrote:

> Hi Fred,
>
> It’s easier to drive the Coverity scan via a CI system.  I don’t know if
> anyone’s done this for the rest of GNUstep, but libobjc2 uses Travis-CI to
> do builds and tests on each push (and on pull request submissions) to
> GitHub, with the tests running on Linux and macOS.  Coverity has
> instructions for integrating the coverity scan with this and pushing the
> results automatically, which removes the need for the manual step.
>
> Note that Travis is a bit primitive and gives only a one-bit state (tests
> passed vs tests failed), so it doesn’t work well in projects where the
> tests are not expected to all pass.
>
> David
>
> > On 21 Jan 2018, at 10:30, Fred Kiefer  wrote:
> >
> > Over this weekend I tried to set up Coverity for GNUstep base. I chose
> base because it is the most widely used part of GNUstep.
> >
> > The first thing I had to learn was that Coverity supports Objective-C
> but only in connection with clang. This isn’t documented anywhere but
> becomes obvious when you read through a few dozens of configuration files.
> So I had to set up a clang only system for which I selected Ubuntu 17/10 on
> a VirtualBox machine. For this setup I tried to follow the instructions on
> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux and they are
> clearly outdated and incorrect. The configuration of GNUstep make needs to
> include „—with-library-combo=ng-gnu-gnu“ and during the compilation of
> libobjc2 I had to use make instead of cmake. As I am no expert in this
> setup I would prefer if somebody with a bit more experiences would correct
> this wiki page. This really would help to save others the frustration I did
> get from not even being able to set up the first few steps of GNUstep.
> Compilation with gcc has been straight forward for more then 15 years now.
> We should get clang/libobjc2 support onto the same level.
> >
> > With that finally in place I was able to run the first Coverity
> analysis. Sadly this could only process one third of your source files. For
> the rest I did get error messages like this:
> >
> > cov-internal-emit-clang-main.cpp:5: assertion failure:
> xlate-ast-types.cpp:1807: assertion failed: ObjCTypeParamType translation
> not implemented.
> >
> > (I had to type this as copy/paste somehow won’t work from my VirtualBox)
> >
> > I have no idea whether this is an issue in clang or Coverity or maybe I
> did forget some required setup step. Just from the file names I would say
> it is something Coverity left out when implementing Objective-C support.
> Maybe switching to an older version of clang could help?
> >
> > The actual scan result ends up in an Sqlite DB you have to upload it to
> Coverity to get some readable information from it. The project is now at
> https://scan.coverity.com/projects/gnustep-base and awaits validation.
> Somebody at Coverity needs to check whether I am actually connected to the
> project I would like to scan. But with most files being left out from the
> analysis the results will be mostly meaningless anyway. I hope to be able
> to see the results in a few days and report whether they look promising or
> not. In the later case I will drop the whole project. Otherwise I would try
> to reach Coverity and discuss the issue with somebody there.
> >
> > Cheers,
> > Fred
> >
> >
> > ___
> > Gnustep-dev mailing list
> > Gnustep-dev@gnu.org
> > https://lists.gnu.org/mailman/listinfo/gnustep-dev
> >
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Coverity Scan for GNUstep?

[David Chisnall]

Hi Fred,

It’s easier to drive the Coverity scan via a CI system.  I don’t know if 
anyone’s done this for the rest of GNUstep, but libobjc2 uses Travis-CI to do 
builds and tests on each push (and on pull request submissions) to GitHub, with 
the tests running on Linux and macOS.  Coverity has instructions for 
integrating the coverity scan with this and pushing the results automatically, 
which removes the need for the manual step.

Note that Travis is a bit primitive and gives only a one-bit state (tests 
passed vs tests failed), so it doesn’t work well in projects where the tests 
are not expected to all pass.

David

> On 21 Jan 2018, at 10:30, Fred Kiefer  wrote:
> 
> Over this weekend I tried to set up Coverity for GNUstep base. I chose base 
> because it is the most widely used part of GNUstep.
> 
> The first thing I had to learn was that Coverity supports Objective-C but 
> only in connection with clang. This isn’t documented anywhere but becomes 
> obvious when you read through a few dozens of configuration files. So I had 
> to set up a clang only system for which I selected Ubuntu 17/10 on a 
> VirtualBox machine. For this setup I tried to follow the instructions on 
> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux and they are 
> clearly outdated and incorrect. The configuration of GNUstep make needs to 
> include „—with-library-combo=ng-gnu-gnu“ and during the compilation of 
> libobjc2 I had to use make instead of cmake. As I am no expert in this setup 
> I would prefer if somebody with a bit more experiences would correct this 
> wiki page. This really would help to save others the frustration I did get 
> from not even being able to set up the first few steps of GNUstep. 
> Compilation with gcc has been straight forward for more then 15 years now. We 
> should get clang/libobjc2 support onto the same level.
> 
> With that finally in place I was able to run the first Coverity analysis. 
> Sadly this could only process one third of your source files. For the rest I 
> did get error messages like this:
> 
> cov-internal-emit-clang-main.cpp:5: assertion failure: 
> xlate-ast-types.cpp:1807: assertion failed: ObjCTypeParamType translation not 
> implemented.
> 
> (I had to type this as copy/paste somehow won’t work from my VirtualBox)
> 
> I have no idea whether this is an issue in clang or Coverity or maybe I did 
> forget some required setup step. Just from the file names I would say it is 
> something Coverity left out when implementing Objective-C support. Maybe 
> switching to an older version of clang could help?
> 
> The actual scan result ends up in an Sqlite DB you have to upload it to 
> Coverity to get some readable information from it. The project is now at 
> https://scan.coverity.com/projects/gnustep-base and awaits validation. 
> Somebody at Coverity needs to check whether I am actually connected to the 
> project I would like to scan. But with most files being left out from the 
> analysis the results will be mostly meaningless anyway. I hope to be able to 
> see the results in a few days and report whether they look promising or not. 
> In the later case I will drop the whole project. Otherwise I would try to 
> reach Coverity and discuss the issue with somebody there.
> 
> Cheers,
> Fred
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 


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

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

Over this weekend I tried to set up Coverity for GNUstep base. I chose base 
because it is the most widely used part of GNUstep.

The first thing I had to learn was that Coverity supports Objective-C but only 
in connection with clang. This isn’t documented anywhere but becomes obvious 
when you read through a few dozens of configuration files. So I had to set up a 
clang only system for which I selected Ubuntu 17/10 on a VirtualBox machine. 
For this setup I tried to follow the instructions on 
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux and they are 
clearly outdated and incorrect. The configuration of GNUstep make needs to 
include „—with-library-combo=ng-gnu-gnu“ and during the compilation of libobjc2 
I had to use make instead of cmake. As I am no expert in this setup I would 
prefer if somebody with a bit more experiences would correct this wiki page. 
This really would help to save others the frustration I did get from not even 
being able to set up the first few steps of GNUstep. Compilation with gcc has 
been straight forward for more then 15 years now. We should get clang/libobjc2 
support onto the same level.

With that finally in place I was able to run the first Coverity analysis. Sadly 
this could only process one third of your source files. For the rest I did get 
error messages like this:

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

(I had to type this as copy/paste somehow won’t work from my VirtualBox)

I have no idea whether this is an issue in clang or Coverity or maybe I did 
forget some required setup step. Just from the file names I would say it is 
something Coverity left out when implementing Objective-C support. Maybe 
switching to an older version of clang could help?

The actual scan result ends up in an Sqlite DB you have to upload it to 
Coverity to get some readable information from it. The project is now at 
https://scan.coverity.com/projects/gnustep-base and awaits validation. Somebody 
at Coverity needs to check whether I am actually connected to the project I 
would like to scan. But with most files being left out from the analysis the 
results will be mostly meaningless anyway. I hope to be able to see the results 
in a few days and report whether they look promising or not. In the later case 
I will drop the whole project. Otherwise I would try to reach Coverity and 
discuss the issue with somebody there.

Cheers,
Fred


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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

On Mon, Jan 15, 2018 at 6:56 AM, Fred Kiefer  wrote:
> As you know I am no fan of management tasks. If you have time for this it 
> would be great if you could set it up. Otherwise I will try to do it over the 
> next weekend.
> A new mailing list would be one way to go, the other possibility is to 
> register the core module maintainers (your, Richard, me) for all the core 
> modules there.

I've no experience with it. I can eventually try it, but that time
might also be usefully spent on setting up our own code hosting.

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

Re: Coverity Scan for GNUstep?

[Richard Frith-Macdonald]

> On 14 Jan 2018, at 18:54, Fred Kiefer  wrote:
> 
> I remember we talked about this before, maybe at the Dublin meeting. There is 
> the option to set up GNUstep on scan.coverity.com to have the code 
> automatically checked for known vulnerabilities. At the time we did discuss 
> this there wasn’t support for Objective-C but this seems to have been added: 
> 
> https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/CWE-CC-Objective-C.pdf
> 
> What are your opinions on this? In the beginning it will require some extra 
> effort to fix the found weaknesses and somehow to flag the false positives. 
> And who should be in charge of getting the reports? The idea here is that 
> only the person registered for the project will get the report to prevent 
> 0-day issues becoming public too soon.

I don't know anything about coverty (I'd forgotten that we talked about it), 
but I'm in favour of any automated checks/testing in principle.  It must be 
worth trying ... as long as we don't get so many false positives that it's just 
too much work.  Presumably the only way to know is to try.


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

Re: Coverity Scan for GNUstep?

[David Chisnall]

On 15 Jan 2018, at 08:11, Riccardo Mottola  wrote:
> 
> Hi,
> 
> I find it interesting. I have of course no idea of the quality of the output, 
> if we will be overthrown with false positives or such, but I think it is 
> worth to try.

My experience with Coverity is that it has a lot of false positives, but the UI 
gives a simple mechanism for flagging them and the scanner is pretty good at 
detecting that something is still a false positive after code around it has 
changed.

> 
> Fred Kiefer wrote:
>> As you know I am no fan of management tasks. If you have time for this it 
>> would be great if you could set it up. Otherwise I will try to do it over 
>> the next weekend.
>> A new mailing list would be one way to go, the other possibility is to 
>> register the core module maintainers (your, Richard, me) for all the core 
>> modules there.

Coverity has pretty good GitHub integration and I’ve found that the web UI is 
very useful, but that the emails are completely useless (they don’t include 
enough context and they don’t give you any of the controls that you want).  I’d 
prefer not to be added to any mailing lists containing the results of the 
scans, but I’d be very interested in checking them periodically and after I 
commit anything.

David


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

Re: Coverity Scan for GNUstep?

[Riccardo Mottola]

Hi,

I find it interesting. I have of course no idea of the quality of the 
output, if we will be overthrown with false positives or such, but I 
think it is worth to try.


Fred Kiefer wrote:

As you know I am no fan of management tasks. If you have time for this it would 
be great if you could set it up. Otherwise I will try to do it over the next 
weekend.
A new mailing list would be one way to go, the other possibility is to register 
the core module maintainers (your, Richard, me) for all the core modules there.


It could make sense to include GWorkspace and a couple of the libraries 
too? I wonder if multiple sources can be given.


A mailing list would allow the delegated person to forward anything to 
the list, altough it means everything would be immediately "public".



Riccardo

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

Re: Coverity Scan for GNUstep?

[Fred Kiefer]

As you know I am no fan of management tasks. If you have time for this it would 
be great if you could set it up. Otherwise I will try to do it over the next 
weekend.
A new mailing list would be one way to go, the other possibility is to register 
the core module maintainers (your, Richard, me) for all the core modules there.

> Am 15.01.2018 um 02:50 schrieb Ivan Vučica :
> 
> I don't recall it, but it seems like a good idea.
> 
> I don't have a preference. Perhaps particular project's maintainer? Or
> perhaps we can (instead of a single person) have a closed-off security
> discussion list, with a limited number of invite-only participants?
> Can we do that on gnu.org?
> 
> Do you feel like setting this up?
> 
> On Sun, Jan 14, 2018 at 6:54 PM, Fred Kiefer  wrote:
>> I remember we talked about this before, maybe at the Dublin meeting. There 
>> is the option to set up GNUstep on scan.coverity.com to have the code 
>> automatically checked for known vulnerabilities. At the time we did discuss 
>> this there wasn’t support for Objective-C but this seems to have been added:
>> 
>> https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/CWE-CC-Objective-C.pdf
>> 
>> What are your opinions on this? In the beginning it will require some extra 
>> effort to fix the found weaknesses and somehow to flag the false positives. 
>> And who should be in charge of getting the reports? The idea here is that 
>> only the person registered for the project will get the report to prevent 
>> 0-day issues becoming public too soon.
>> 
>> Fred

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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

I don't recall it, but it seems like a good idea.

I don't have a preference. Perhaps particular project's maintainer? Or
perhaps we can (instead of a single person) have a closed-off security
discussion list, with a limited number of invite-only participants?
Can we do that on gnu.org?

Do you feel like setting this up?

On Sun, Jan 14, 2018 at 6:54 PM, Fred Kiefer  wrote:
> I remember we talked about this before, maybe at the Dublin meeting. There is 
> the option to set up GNUstep on scan.coverity.com to have the code 
> automatically checked for known vulnerabilities. At the time we did discuss 
> this there wasn’t support for Objective-C but this seems to have been added:
>
> https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/CWE-CC-Objective-C.pdf
>
> What are your opinions on this? In the beginning it will require some extra 
> effort to fix the found weaknesses and somehow to flag the false positives. 
> And who should be in charge of getting the reports? The idea here is that 
> only the person registered for the project will get the report to prevent 
> 0-day issues becoming public too soon.
>
> Fred
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Coverity Scan for GNUstep?

[Fred Kiefer]

I remember we talked about this before, maybe at the Dublin meeting. There is 
the option to set up GNUstep on scan.coverity.com to have the code 
automatically checked for known vulnerabilities. At the time we did discuss 
this there wasn’t support for Objective-C but this seems to have been added: 

https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/CWE-CC-Objective-C.pdf

What are your opinions on this? In the beginning it will require some extra 
effort to fix the found weaknesses and somehow to flag the false positives. And 
who should be in charge of getting the reports? The idea here is that only the 
person registered for the project will get the report to prevent 0-day issues 
becoming public too soon.

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