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!
Message-Id: <20060419080203.GB10098@vanheusden.com>
References: <rt-3665-16198.7.95988654698661@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <rt-3665-16198.7.95988654698661@krbdev.mit.edu>
Organization: www.unixexpert.nl
Return-Receipt-To: <folkert@vanheusden.com>
Read-Receipt-To: <folkert@vanheusden.com>
Reply-BY: Thu Apr 20 09:41:46 CEST 2006
User-Agent: Mutt/1.5.10i
RT-Send-Cc: 
Content-Length: 2551

Ok, thanks for your reply and for considering!

On Tue, Apr 18, 2006 at 05:41:44PM -0400, Ken Raeburn via RT wrote:
> 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