Coding practices proposals
dalmeida at MIT.EDU
Thu Mar 17 22:31:22 EDT 2011
My take is that, in general, you want a cleanup handler for anything in the
function's top-level scope -- even if you free it sooner. The rationale is
that code changes. Perhaps today, the codepaths are such that you always
free within the function somewhere. However, as the code changes, someone
may add another codepath and now the pointer is no longer freed.
Also, having a standard practice with cleanup handlers makes it easier for
reviewers to verify that everything is getting cleaned up.
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
Sent: Thursday, March 17, 2011 3:48 PM
To: ghudson at mit.edu
Cc: krbdev at mit.edu
Subject: Re: Coding practices proposals
I've been thinking a bit more about freeing things in the cleanup
handler rather than sooner.
I wonder if that's overly restrictive.
My assumption is that you want it to be easy to make sure that the value
is freed. Here are some situations where I'm not sure that makes sense:
* If you are using the iff-ladder style of cleanup and don't have gotos
it seems reasonable to free and null sooner
* If a pointer is going out of scope it seems reasonable to free. I
don't think we want to force things into top most scope just to clean
them up in a particular place
* If the value has fairly short life, for example it is an intermediate
used by one call.
krbdev mailing list krbdev at mit.edu
More information about the krbdev