On Fri, May 25, 2012 at 11:25 AM, Ken Goldman <kgold...@us.ibm.com> wrote: > On 5/25/2012 11:03 AM, Steffen DETTMER wrote: >> >> I think crashing with NULL is quite good: a must-not-happen situation >> leads to a defined dead of SIGSEGVs, at least for platforms supporting >> that, typically with good aid for debuggin (like core files or halting >> debuggers providing a backtrace). Maybe adding an assert() before. > That's not the normal library behavior. Agreed - runtime crashes or calls to abort() are not appropriate in production code (ie, NDEBUG is defined).
> 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 int). For example, the return value of alloc() should be validated (lack of validation happens more often than one would expect). If pointer validation is occuring, then the [pointer validation] problem with free() is a non sequitur *IF* free() occurs in the same function. > 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 envirnoment. In my mind's eye, it demonstrates a level of slopiness that makes me suspicious. I understand many others think differently than me, and it was not my intention to start a flame war. Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
