[krbdev.mit.edu #3665] idea for kerberos!

[Folkert van Heusden via RT]

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