[splint-discuss] memory leak detection

David Evans evans at cs.virginia.edu
Sun Nov 2 09:59:05 EST 2003

On Sun, 2 Nov 2003, Roland Illig wrote:

> On Sat, Nov 01, 2003 at 09:58:46PM -0500, David Evans wrote:
> >
> > Splint's analysis isn't sophisticated enough to figure this out.  If you
> > do,
> >
> >         free(this_string);
> >         this_string = NULL;
> >
> > it will prevent the warning.
> I just checked the manual, and in clause 5.2.1#5 it states that
>     "After the release obligation is transferred, the original reference
>     is a dead pointer and the storage it points to may not be used."
> 5.2.1#3 says:
>     * assign it to an external reference declared with an only annotation
> According to these statements, the following program should be ok,
> shouldn't it?

The warning isn't complaining directly about a memory leak here --- its
complaining about the state of this_string being different along two
paths.  Along the true path, it does
	last_string = this_string;
which makes this_string dependent (but live).  On the false branch, it
does free(this_string) which makes this_string dead.  As the warning

  The state of a variable is different depending on which branch is taken.
  This means no annotation can sensibly be applied to the storage. (Use
  -branchstate to inhibit warning)

Splint's analysis avoids path explosion by merging states after multi-path
statements, but in this case the states are inconsistent so a warning is
produced.  If splint had more path sensitive analyses, or dealt with local
variable assignments in a better way, it would be able to avoid producing
the spurious warning here.

--- Dave

More information about the splint-discuss mailing list