[splint-discuss] incomplete deallocation

[Greg White]

> Date: Mon, 10 Nov 2008 07:04:21 -0800
> From: Michael.Wojcik at microfocus.com
> To: splint-discuss at cs.virginia.edu
> Subject: Re: [splint-discuss] incomplete deallocation
> 
>> 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.

Yes the code has a *n.  I wasn't in front of the code when I typed in the
email.  The memset is kill a splint warning of n not being fully defined (or
something like that, I am not in front of my code).
 
> 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.)

Thank you for the suggestions.  I will try them out.  
 
> [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 noticed that.  I did a diff between my executable before and after
fixing up some splint warnings and there wasn't any difference, except
when I added a missing check for null after malloc.
 
>> 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.

I would really like to help with that, but as you can see I am not close
to being an expert in either C or splint.  I do try to help out projects
when I can.  I just wrote some code for a open source project and
it is this code I am using splint on.
 
Thanks for the tips,
 
_________________________________________________________________
Get 5 GB of storage with Windows Live Hotmail.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008