[asterisk-dev] [Code Review]: automagically set a pointer to null after it is freed with ast_free

[David Vossel]

----- Original Message -----
> From: "Simon Perreault" <simon.perreault at viagenie.ca>
> To: "David Vossel" <dvossel at digium.com>
> Cc: "Asterisk Developers" <asterisk-dev at lists.digium.com>, sst at sil.at
> Sent: Friday, September 16, 2011 9:55:51 AM
> Subject: Re: [Code Review]: automagically set a pointer to null after it is freed with ast_free
> David Vossel wrote, on 09/16/2011 10:47 AM:
> > I don't think we can change the behavior of ast_free(), but this
> > functionality seems useful. I write the following lines all the
> > time.
> >
> > ast_free(blah);
> > blah = NULL;
> 
> Well, you should stop doing that, for the reasons previously stated.
> 
> Here's a "prisoner's dilemma-style" matrix to illustrate:
> 
> | Set to null | Do not set to null
> --------------------+-----------------+------------------------------------
> Double free | Undetectable | Detectable with Valgrind or similar

undetectable, because it won't happen.

> Use of freed memory | Immediate crash | Detectable with Valgrind or
> similar
> As you can see, the "do not set to null" option is better overall.

I'd rather have an immediate crash due to someone accessing a NULL pointer than someone accessing a pointer to freed memory.  In the pointer to freed memory case I have to use Valgrind to find the source of the problem which I don't have to do with the NULL pointer access.  Accessing a NULL pointer also produces immediate reproducible consistent crash results every time.

This really comes down to one's own personal opinions and coding style.   I always clear pointers that point to freed memory.  I just can't see anything good coming from leaving dangling pointers around.

~David


> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
> STUN/TURN server --> http://numb.viagenie.ca