Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dg!fs06!pds From: pds@lemming.webo.dg.com (Paul D. Smith) Newsgroups: comp.lang.c Subject: Re: Just a minor new twist on free() Message-ID: Date: 3 Oct 90 14:31:26 GMT References: <7365@darkstar.ucsc.edu> <1990Oct02.132313.6659@virtech.uucp> Sender: root@dg.dg.com Organization: NSDD/ONAD, Data General Corp., Westboro, MA Lines: 82 In-reply-to: cpcahil@virtech.uucp's message of 2 Oct 90 13:23:13 GMT In article <1990Oct02.132313.6659@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: [] In article pds@lemming.webo.dg.com (Paul D. Smith) writes: [] >It should be pointed out that in ANSI C free(NULL) is defined, and is [] >legal (any conforming implementation of free() must ignore being [] >passed a NULL pointer). [] [] While this is a true statement, I would never recommend that one [] take advantage of this feature. If you know the variable is NULL [] don't pass it to free. Obviously if you know it's NULL, why would you call free()? This is a no-brainer. The problem arises when you *don't* know if it's NULL or not -- I thought that's why we have the if() test! [] The performance cost of the following statement: [] [] if( ptr != NULL ) [] free(ptr); [] [] as opposed to: [] [] free(ptr); [] [] will be unmeasurable in most, if not all, circumstances. Well, IMHO, this is just silliness. What are you saying, that no one should use ANSI extensions if they have an ANSI compiler just because they didn't *used* to be legal? While your simple case might indeed not be much of a performance hit, what about something like: #define ARRAY_LEN 10000 char *array[ARRAY_LEN], *ap; int i; for (ap = array, i = 0; i < ARRAY_LEN; ++i, ++ap) { if (ap != NULL) free(ap) } Now, *this* is a significant performance hit, if you consider an extra 10000 comparisons. Before you retort about using memset() or bzero(), please read the FAQ on NULL pointers ... and no, I wouldn't do it this way either, but it is not hard to see where extraneous tests *can* cause some loss of performance, not to mention loss of programmer time typing them in! Besides, I think it is correct behavior for free() to handle a NULL pointer, and it should have done all along. [] Anyway, this is really a moot point because you should never be calling [] free() unless you KNOW WHAT IS IN THE PTR that you will be passing to it. [] If you don't, then something is wrong with your code. So what are you saying, that in the above case I should have a bitmap with ARRAY_LEN bits which tells me which of the pointers in `array' actually have values and which are NULL? More silliness. [] In addition, by adding the if() you get code that is portable [] across all implementations. Ok, now *this* is a valid concern. So, rewrite the macro in question: #ifdef __STDC__ #define smart_free(_p) { free(_p); (_p)=NULL; } #else #define smart_free(_p) { if ((_p)!=NULL) { free(_p); (_p)=NULL; } } #endif -- paul ----- ------------------------------------------------------------------ | Paul D. Smith | pds@lemming.webo.dg.com | | Data General Corp. | | | Network Services Development | "Pretty Damn S..." | | Open Network Applications Department | | ------------------------------------------------------------------