Skip Menu |
 

Date: Tue, 18 Apr 2006 18:23:13 +0200
From: Folkert van Heusden <folkert@vanheusden.com>
To: krb5-bugs@mit.edu
Subject: idea for kerberos!
Hi,

Maybe it is a good idee to get kerberos scanned by coverity!
http://scan.coverity.com/
Coverity is an excellent static sourcecode analyzer which found quit a
few bugs in the linux kernel. I'm NOT in any way related to them
(altough I'm really hoping they'll scan multitail as well). Please see
that page for a list of all the projects they're already scanning.


Folkert van Heusden

--
www.vanheusden.com/multitail - multitail is tail on steroids. multiple
windows, filtering, coloring, anything you can think of
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3665] idea for kerberos!
Date: Tue, 18 Apr 2006 17:41:27 -0400
To: MIT Kerberos RT <rt@krbdev.mit.edu>
RT-Send-Cc:
On Apr 18, 2006, at 17:11, Folkert van Heusden via RT wrote:
Show quoted text
> Maybe it is a good idee to get kerberos scanned by coverity!
> http://scan.coverity.com/
> Coverity is an excellent static sourcecode analyzer which found quit a
> few bugs in the linux kernel. I'm NOT in any way related to them
> (altough I'm really hoping they'll scan multitail as well). Please see
> that page for a list of all the projects they're already scanning.


Yeah, I thought about this after seeing some of the work they've done
on GNU Emacs recently. But a couple of issues come to mind:

1) They've gotten quite a few false positives in the reports I've
seen. The most common is probably the "possibly uninitialized" type
where initialization happens in a path that also includes a setting
of a second variable that you need to have in order to reach the site
of the warning; i.e., if the variable being warned about wasn't set,
then other conditions necessary to reach the warning site couldn't be
met.

2) If we (MIT, or some other developers who want to help out) have
got the cycles to chase down these reports, we could start by
applying OCD-like focus to cleaning up the warnings GCC spits out
during a build. That's not to say that using the Coverity tool
wouldn't be useful. But we've got other, simpler things we could do
first to knock off the more obvious possible problems, and mildly
"interesting" data/control flow constructs that trigger false
positives in simple analyses like these, and we aren't doing enough
of *that* currently in my opinion.

If you feel like tackling either of these -- GCC warnings or Coverity
-- and sorting through the false positives and giving us patches for
the rest, I expect we'd be happy to take them.... :-)

Ken

P.S. There's also Splint, which I've used a few times on parts of
our code to search for possible problems; you'll even find some
Splint annotations in the code in a few places. Unfortunately,
Splint has problems with functions like realloc() where the memory
management behavior goes two different ways depending on success or
failure.
Date: Wed, 19 Apr 2006 10:02:04 +0200
From: Folkert van Heusden <folkert@vanheusden.com>
To: Ken Raeburn via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #3665] idea for kerberos!
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.4KiB
Ok, thanks for your reply and for considering!

On Tue, Apr 18, 2006 at 05:41:44PM -0400, Ken Raeburn via RT wrote:
Show quoted text
> On Apr 18, 2006, at 17:11, Folkert van Heusden via RT wrote:
> > Maybe it is a good idee to get kerberos scanned by coverity!
> > http://scan.coverity.com/
> > Coverity is an excellent static sourcecode analyzer which found quit a
> > few bugs in the linux kernel. I'm NOT in any way related to them
> > (altough I'm really hoping they'll scan multitail as well). Please see
> > that page for a list of all the projects they're already scanning.
>
>
> Yeah, I thought about this after seeing some of the work they've done
> on GNU Emacs recently. But a couple of issues come to mind:
>
> 1) They've gotten quite a few false positives in the reports I've
> seen. The most common is probably the "possibly uninitialized" type
> where initialization happens in a path that also includes a setting
> of a second variable that you need to have in order to reach the site
> of the warning; i.e., if the variable being warned about wasn't set,
> then other conditions necessary to reach the warning site couldn't be
> met.
>
> 2) If we (MIT, or some other developers who want to help out) have
> got the cycles to chase down these reports, we could start by
> applying OCD-like focus to cleaning up the warnings GCC spits out
> during a build. That's not to say that using the Coverity tool
> wouldn't be useful. But we've got other, simpler things we could do
> first to knock off the more obvious possible problems, and mildly
> "interesting" data/control flow constructs that trigger false
> positives in simple analyses like these, and we aren't doing enough
> of *that* currently in my opinion.
>
> If you feel like tackling either of these -- GCC warnings or Coverity
> -- and sorting through the false positives and giving us patches for
> the rest, I expect we'd be happy to take them.... :-)
>
> Ken
>
> P.S. There's also Splint, which I've used a few times on parts of
> our code to search for possible problems; you'll even find some
> Splint annotations in the code in a few places. Unfortunately,
> Splint has problems with functions like realloc() where the memory
> management behavior goes two different ways depending on success or
> failure.


Folkert van Heusden

--
Temperature outside: 10.562500, temperature livingroom: 19.7
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
We are now regularly using Coverity to scan the source tree.