Re: Compile Time Memory Leak Analyses

[Joe Buck <jbuck at synopsys dot COM>]

I wrote:
> > Not at all.  Undecidability theorems mean only that an analysis routine
> > that tries to establish whether property P is true must return a
> > three-valued result (yes, no, and "I don't know").  gcc is full of
> > such code.  If there are many cases where a definite answer can be
> > given, the tool can be useful.
> > 
> > After all, reachability is also undecidable, but we still eliminate dead
> > code.

Joern writes:
> Well, but that's an optimization.  We optimize only when we know that it
> is safe (at least that's the theory ;-), so while we can't tolerate false
> positives, we can tolerate false negatives.
> 
> However, for warnings, false positives are extremely annoying, while
> false negatives mean that you can miss potential bugs while you are
> lulled into a false security that the compiler will warn about problems.
> 
> So we set ourselves up for a warning that is likely to become as awkward as
> the uninitialized warnings.

It has been frequently argued that gcc should make no attempt to try to
detect dangerous condition X (e.g. aliasing violations, or leaks in this
case), because it cannot detect all violations and would thus lead users
into a false sense of security.

I disagree; I think we're doing the world a service if we detect more
bugs.  Perhaps the limitations can be stressed in option naming:
-Wobvious-leaks, -Wobvious-alias-violations.  As the names suggest,
I would bias the test to avoid reporting any false positives.  The
tests could then be enabled as part of -Wall.