Just a minor new twist on free()

[Paul D. Smith]

In article <1990Oct02.132313.6659 at virtech.uucp> cpcahil at virtech.uucp (Conor P. Cahill) writes:

[] In article <PDS.90Oct1095707 at lemming.webo.dg.com> pds at 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 at lemming.webo.dg.com |
| Data General Corp.                     |                         |
| Network Services Development           |   "Pretty Damn S..."    |
| Open Network Applications Department   |                         |
 ------------------------------------------------------------------