Coverity Scan for GNUstep?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Ivan Vučica-2
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 <[hidden email]> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> 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 <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Riccardo Mottola-5
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

David Chisnall-7
On 15 Jan 2018, at 08:11, Riccardo Mottola <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Richard Frith-Macdonald-9
In reply to this post by Fred Kiefer


> On 14 Jan 2018, at 18:54, Fred Kiefer <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Ivan Vučica-2
In reply to this post by Fred Kiefer
On Mon, Jan 15, 2018 at 6:56 AM, Fred Kiefer <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

David Chisnall-5
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 <[hidden email]> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Ivan Vučica-2
@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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Fred Kiefer


> Am 21.01.2018 um 22:04 schrieb Ivan Vučica <[hidden email]>:
>
> @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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Ivan Vučica-2

On Sun, Jan 21, 2018 at 9:12 PM Fred Kiefer <[hidden email]> wrote:


> Am 21.01.2018 um 22:04 schrieb Ivan Vučica <[hidden email]>:
>
> @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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Fred Kiefer


> Am 21.01.2018 um 22:19 schrieb Ivan Vučica <[hidden email]>:
>
>
> On Sun, Jan 21, 2018 at 9:12 PM Fred Kiefer <[hidden email]> wrote:
>
>
> > Am 21.01.2018 um 22:04 schrieb Ivan Vučica <[hidden email]>:
> >
> > @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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Patryk Laurent
In reply to this post by Fred Kiefer


> On Jan 21, 2018, at 02:30, Fred Kiefer <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

David Chisnall-7
In reply to this post by Fred Kiefer
On 21 Jan 2018, at 21:33, Fred Kiefer <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Fred Kiefer
In reply to this post by Fred Kiefer


> Am 21.01.2018 um 11:30 schrieb Fred Kiefer <[hidden email]>:
>
> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Ivan Vučica-2
On Mon, Jan 22, 2018 at 10:23 PM, Fred Kiefer <[hidden email]> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Ivan Vučica-2
On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica <[hidden email]> wrote:

> On Mon, Jan 22, 2018 at 10:23 PM, Fred Kiefer <[hidden email]> 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
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Fred Kiefer


> Am 25.01.2018 um 00:59 schrieb Ivan Vučica <[hidden email]>:
>
> On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica <[hidden email]> wrote:
>> On Mon, Jan 22, 2018 at 10:23 PM, Fred Kiefer <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Coverity Scan for GNUstep?

Richard Frith-Macdonald-9


> On 25 Jan 2018, at 07:41, Fred Kiefer <[hidden email]> wrote:
>
>
>
>> Am 25.01.2018 um 00:59 schrieb Ivan Vučica <[hidden email]>:
>>
>> On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica <[hidden email]> wrote:
>>> On Mon, Jan 22, 2018 at 10:23 PM, Fred Kiefer <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
12