Coding practices proposals

Danilo Almeida 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.

- Danilo

-----Original Message-----
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
Sam Hartman
Sent: Thursday, March 17, 2011 3:48 PM
To: ghudson at
Cc: krbdev at
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

More information about the krbdev mailing list