Just a minor new twist on free()

[Conor P. Cahill]

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.90Oct3103126 at lemming.webo.dg.com> pds at lemming.webo.dg.com (Paul D. Smith) writes:
>In article <1990Oct02.132313.6659 at virtech.uucp> cpcahil at 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