lclint-interest message 56

From horning@hector.mti.sgi.com Fri Mar 22 12:53:53 1996
From: horning@hector.mti.sgi.com (Jim Horning)
Date: Thu, 21 Mar 1996 11:44:21 -0800
Reply-To: lclint-interest@larch.lcs.mit.edu, softverf@leopard.cs.byu.edu
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: lclint-interest@larch.lcs.mit.edu
Subject: (Fwd) Re: LCLint
Cc: horning@hector.mti.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Forwarded mail from Corky Cartwright 

Date: Thu, 21 Mar 1996 13:12:12 -0600 (CST)
From: Corky Cartwright 
To: evans@cs.virginia.edu (David Evans)
Subject: Re: LCLint
Cc: softverf@leopard.cs.byu.edu, horning


>I think Jim Horning made the main point I want to make, and that is that
>unlike in formal verification, in the static checking area we do not
>need to view soundness as an essential property.

The real issue in LCLint is how effectively it finds bugs.  The
term "soundness" is misleading in this context because LCLint does
not perform static checking in usually accepted meaning of the term.
(What properties are being checked?)  Rather, LCLint is a programming tool
that attempts to help programmers statically identify memory bugs.  What I
would like to know is given representative programs that may or may not
have memory bugs, how often does LCLint fail to find a memory bug and
how often does it signal a false alarm.

-- Corky Cartwright

---End of forwarded mail from Corky Cartwright 

Well, gang, any experience out there yet?

Jim H.
horning@sgi.com  (415) 933-4067  FAX (415) 933-6175
http://reality.sgi.com/horning/home.html              O-
Silicon Graphics, 2011 N. Shoreline Blvd., MS 178, Mountain View, CA 94043