On 5/25/2012 12:09 PM, Jeffrey Walton wrote:
My typical design pattern is:
void *ptr = NULL;
do stuff which may in some branches allocate the pointer
free(ptr);
This is very old, and has not evolved as security needs have changed
(forgive me if I read too much into it). For example, the return
value of alloc() should be validated (lack of validation happens more
often than one would expect). If pointer validation is occurring, then
the [pointer validation] problem with free() is a non sequitur *IF*
free() occurs in the same function.
It was s snippet. Of course I check the return values!
BTW, if the alloc fails, the ptr will be NULL, so free(ptr) at the end
is still safe.
If the library crashes on free(NULL), you're just making people like me
do this everywhere:
if (ptr != NULL) free (ptr);
If the free() is in a different function than the alloc(), the pointer
should be checked. Though legal C/C++, it makes no conceptual sense to
free a NULL pointer. I don't believe its an appropriate style to use
in the 2010's in a hostile environment. In my mind's eye, it
demonstrates a level of sloppiness that makes me suspicious.
I don't see anything sloppy or risky about it. The standard clearly
says free(NULL) is a legal noop. Why bother doing
if (ptr != NULL)
when the library already does it.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
