[16696] in Kerberos_V5_Development
Re: Coding practices proposals
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Mar 17 23:44:47 2011
Mime-Version: 1.0 (Apple Message framework v1082)
From: Ken Raeburn <raeburn@mit.edu>
In-Reply-To: <201103172133.p2HLX28E020953@outgoing.mit.edu>
Date: Thu, 17 Mar 2011 23:44:43 -0400
Message-Id: <0DEAA272-9383-403E-9B6B-7AE10AFFDFF1@mit.edu>
To: "krbdev@MIT.EDU List" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Minor editorial (I think) points:
On Mar 17, 2011, at 17:33, ghudson@MIT.EDU wrote:
> 1. When transferring ownership of a pointer (such as when returning an
> allocated value to a caller via an output parameter), null out the old
> owner pointer unless it is immediately going out of scope.
... or being freed? (E.g., if the old owning reference lives in a structure that gets freed on the next line.)
> 3. Initialize variables containing owner pointers to NULL. Free them
> in the function's cleanup handler, even if it would be possible to
> free them sooner.
If you take "free them" to mean "call the appropriate 'free' function", as I did on first reading, this means, "even if in some code paths you do free them sooner". But if you take "free them" to mean "perform the call that actually releases the storage", then the above description seems to discourage doing it any sooner, "even if it would be possible". I think the former is the better approach.
Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
