Re: Compile Time Memory Leak Analyses

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> 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.

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

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

A commercial lint package I'm quite fond of "solves" this problem by
having multiple layers of warnings.  For example, "may not have been
initialized", "conceivably not initialized", and "not initialized".
Since every warning can be individually enabled/disabled, a user can
choose whether or not to include possible false hits in the output.
For what it's worth, I've found this to be very useful.

        --jtc
-- 
J.T. Conklin
RedBack Networks