[splint-discuss] incomplete deallocation

[Michael Wojcik]

> From: splint-discuss-bounces at cs.virginia.edu [mailto:splint-discuss-
> bounces at cs.virginia.edu] On Behalf Of Greg White
> Sent: Sunday, 09 November, 2008 12:28
>
> >> I do the following in my code:
> >>
> >>   n = malloc(sizeof(nk_hdr));

The following would be better:

	nk_hdr *n;
	n = malloc(sizeof *n);

That's less cluttered (the operand of the sizeof operator only needs to
be parenthesized if it's a type identifier), and it's typesafe; the
malloc statement doesn't need to include the purported type of the
object pointed to by n.

> >>   memset(n, 0, sizeof(n));

I hope you acutally have "sizeof *n" there (again, sizeof's operand does
not have to be parenthesized when it's an object identifier). Otherwise
you only cleared out a pointer-sized area.

A better way to initialize dynamically-allocated structures is with
structure copy:

	static const nk_hdr nk_hdr0 = {0};
	...
	n = malloc(sizeof *n);
	*n = nk_hdr0;

This has a number of advantages:

- It's simpler, less cluttered, and clearer.
- It's typesafe; you'll get an error if the type of n changes, and you
forget to change the initialization statement.
- It's guaranteed to initialize all types correctly. It's possible for a
C implementation to have a null pointer representation that's not
binary-zeroes.
- It avoids the mistake that your memset line above makes.

(Note that the "{0}" initializer initializes every member of nk_hdr0 to
its type-appropriate zero value: integer types to 0, floating types to
0.0, pointers to null, and aggregate types to zero recursively. The "=
{0}" is actually not necessary, as all static variables are implicitly
initialized this way, but for a dedicated initializer I like to make it
explicit as documentation.)

[Brian's already answered your actual question.]

> Thanks.  I used /*@dependent@*/ on key_name and splint stopped warning
> and the program still works.

Of course Splint annotations have no effect on the code generated by
your compiler, so they should never affect how the program works.
(Unless there's a C implementation other than Splint that recognizes
Splint annotations and alters its code generation, I suppose, but I've
never heard of one.)

> I must say the manual could use a little work.  For example it gives
> examples of bad code, but it never shows you the good version of the
> bad code.

Agreed. But someone has to take on the job of updating it.

I think most of the people still doing research in this area (static
code analysis) have either moved on to other languages, or to commercial
products, which have the advantage of substantial R&D budgets. Splint
maintenance is mostly being done by a handful of stubborn holdouts -
which I certainly respect, but their resources for the project are
necessarily limited.

So while it's always useful to have suggestions for improvement, it's
much more useful to actually contribute an improvement.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus