[16699] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: Coding practices proposals

daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Mar 18 01:52:39 2011

Mime-Version: 1.0 (Apple Message framework v1082)
From: Ken Raeburn <raeburn@mit.edu>
In-Reply-To: <1300423184.2397.621.camel@t410>
Date: Fri, 18 Mar 2011 01:52:35 -0400
Message-Id: <4CB72523-6E15-4684-A9C8-D545E90990BF@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

On Mar 18, 2011, at 00:39, Greg Hudson wrote:
> Ken wrote:
>> 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.
> 
> I don't understand the difference between "calling the appropriate free
> function" and "performing the call that actually releases the storage".

If you allocate storage, then call a free function and set the pointer to null, and then call the free function again, both are "calls to the appropriate free function", but only the first will "actually release the storage".

To put it another way, were you trying to say "the cleanup code at the end of the function is where you should be freeing them, and not any place else even though you could (though perhaps only in a subset of control flows) with the previously mentioned exception of storage allocated in loops"?  Or, "you should have free calls in the cleanup code, to be on the safe side, even if you may have freed it earlier (and nulled out the pointer) in certain cases"?

> Ken also wrote:
>> ... or being freed?
> 
> Yes, definitely.  I was thinking of that as a form of going out of
> scope, but technically it isn't.

And I'm all about the technical nit-picking. :-)

Ken
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post