[asterisk-dev] [Code Review]: automagically set a pointer to null after it is freed with ast_free
dvossel at digium.com
Fri Sep 16 10:14:19 CDT 2011
----- 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
> 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.
> 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
More information about the asterisk-dev