In-Reply-To: <rt-3665-16197.4.67344188191397@krbdev.mit.edu>
References: <rt-3665-16197.4.67344188191397@krbdev.mit.edu>
MIME-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <46D17D5C-7337-4D8F-9866-5AAF22D75623@mit.edu>
Content-Transfer-Encoding: 7bit
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: 
Content-Length: 2128

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.