free (NULL)

[Boyd Roberts]

In article <17486:Jun611:18:1690 at stealth.acf.nyu.edu> brnstnd at stealth.acf.nyu.edu (Dan Bernstein) writes:
>
>Again, it doesn't matter whether internally you malloced the memory or
>used a static area. Just never return a chunk of memory that's *defined*
>to be malloc()ed. (This is what he said.)
>

No, that's not what I said.  I said you could return what you liked as long
as you defined what to do with the object when you'd finished with it.

>To put it differently: Never, ever, ever pass internally malloc()ed
>memory up to your parent (this is what I said)---but, as always in C,
>feel free to apply the as-if rule.
>

Totally, incorrect.  I'll return whatever I like.  There is no problem.
When I return a simple malloc()'d object my interface definition will
say `call free() to free it'.  By simple, I mean an object that will
be completely free()'d by the one malloc call.

If the object is complex, then I'll use a finished_with_this_thing(p)
function.  But only for complex objects, such as:

    struct tricky
    {
	int	flags;
	char	*name;
    };

Because, just calling malloc() will do the wrong thing.  It won't free
what `name' points to.  So free_tricky() goes:

    free_tricky(p)
    struct tricky	*p;
    {
	free(p->name);
	free((char *)p);
    }

It is overengineering to have a free function for every type of object.
It the object is derived from a simple malloc, the free function is free().
Sure, you may like the style of it, but who needs code full of redundancies?

   free_special_thing(p)
   char	*p;
   {
	free(p);
   }

No, use free() in line.  Define the interface and stick by it.


Boyd Roberts			boyd at necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''