Path: utzoo!attcan!uunet!virtech!cpcahil From: cpcahil@virtech.uucp (Conor P. Cahill) Newsgroups: comp.lang.c Subject: Re: Just a minor new twist on free() Message-ID: <1990Oct04.110928.16788@virtech.uucp> Date: 4 Oct 90 11:09:28 GMT References: <7365@darkstar.ucsc.edu> <1990Oct02.132313.6659@virtech.uucp> Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill) Organization: Virtual Technologies Inc., Sterling VA Lines: 97 It appears you took my comments as a personal attack, which they were not meant to be. However, you raised some points that I will respond to... In article pds@lemming.webo.dg.com (Paul D. Smith) writes: >In article <1990Oct02.132313.6659@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >[] 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! You say this and then you make an argument for calling free with a NULL anyway? >[] The performance cost of using if( ptr!= NULL) free(ptr) as opposed to >[] free(ptr) (with no if) 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? I am saying that the if(ptr!=NULL) is almost a "free" operation (using only one or two instructions on many machines). If you use it, the code will work correctly on ANSI and pre-ANSI, and the peformance difference will not be measurable. (The key word is measurable). >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 No it is not. Actually, if array has greater than a small percentage of NULL pointers, the savings of the function call by the if test will be substantial. Rember, comparisons (especially comparisons against zero) are a very cheap operation. Function calls are not. >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 I didn't meantion bzero or memset anywhere so I'm not sure why the reference is here. >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! Before you say it *can*, try it and you will find that you can't measure the difference in a *real* program. >Besides, I think it is correct behavior for free() to handle a NULL >pointer, and it should have done all along. I don't, but that is just personal opinion and both of us can have our own. >[] 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. No. if you assigned null to all the pointers originally, then you only need to call free if the pointer is not NULL. >[] 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 While this is a valid construct, I still maintain that you won't be able to measure the difference in execution time and therefore make your code more complex needlessly. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170