Why doesn't free(p) set p to NULL?

问题:

Any reasons why this can not be standard behavior of free()?

multiple pointers pointing to the same object:

#include <stdlib.h>
#include <stdio.h>

void safefree(void*& p)
{
    free(p); p = NULL;
}

int main()
{
    int *p = (int *)malloc(sizeof(int));
    *p = 1234;
    int*& p2 = p;
    printf("p=%p p2=%p\n", p, p2);
    safefree((void*&)p2);
    printf("p=%p p2=%p\n", p, p2);
    safefree((void*&)p); // safe

    return 0;
}

assignment from malloc demands cast from void*

vice versa:

safefree() demands cast to void*& (reference)

回答1:

If it did, you would have to pass a pointer to a pointer to the function:

int * p = malloc( sizeof( int ));
free( & p );

which I'm sure many people would get wrong.

回答2:

Simple answer: because you might be freeing an expression, e.g. free(find_named_object("foo")).

In more detail: The free function takes a void* parameter, which is the address of the memory to free. This doesn't confer to the function any knowledge of the original variable that supplied the address (or, for that matter, whether there even exists a variable). Just setting the parameter passed in to NULL would do nothing either, since it's just a local copy of the address.

回答3:

Bjarne Stroustrup discussing whether the delete operator should zero its operand. It's not the free() function, but it's a good discussion anyway. Consider points like:

• What would be zeroed out if you said free(p + 1)?
• What if there are two pointers to the memory? Why only set one to null if a dangling reference is still left behind?

He also says it was intended but never happened with operator delete:

C++ explicitly allows an implementation of delete to zero out an lvalue operand, and I had hoped that implementations would do that, but that idea doesn't seem to have become popular with implementers.

回答4:

C function parameters are always passed by value, so in order to modify the pointer passed to free() you would need to pass a pointer to the pointer being deallocated, which can lead bugs caused by forgotten & operators.

Secondly, if that pointer had any aliases, the programmer would still be responsible for nulling them out. I could see problems caused by programmers assuming that all references were set to NULL.

Finally, it's not always necessary to set the pointer to NULL. Imagine a function which allocates some memory, does some work and frees it before returning. I could see how setting the pointer to NULL might not seem optimal.

回答5:

Because function parameters are passed by value in C. That is, if p == 0x12345 you pass '0x12345' to free(), not p "itself".

回答6:

In C, calling a function can never alter the value of the parameters you pass in, so if free(p) altered the value of p by setting it to NULL then this behaviour would be very non-standard indeed.

回答7:

With reference to the quote from Stroustrup about delete, Peter Norvig also makes a similar remark. He writes (not about C++!):

"Nothing is destroyed until it is replaced"
 - Auguste Comte (1798-1857) (on the need for revolutionary new
   theories (or on the need to do x.f = null in garbage-collected
   languages with destructors))

In my C code, I find the following macro very useful:

#define free(p) free((void *)(p)),(p)=NULL /* zero p */

This, as written, uses its argument twice. But this isn't a problem, as any usage such as free(p++) or free(find_named_object("foo")) will give a compile-time error (lvalue required). And you can hide the macro by using (free)(p++), or by calling it something else e.g. FREE.

回答8:

Casting the reference from int *& to void *& is not guaranteed to work. int * simply does not have to have the same size, representation nor alignment requirements as void *.

The proper C++ solution would be to use templates, as Neil Butterworth suggests in a comment. And neither of these ways work in C, obviously - which is where free() comes from.

回答9:

What's this maniac thing with zero ? There are other numbers !

Why should a free pointer should contain zero more than any other distinguished value ?

Practically, in my C++ code I often use watchdog objects and when freeing a pointer reset it not to zero but to the watchdog. That has the added benefit that the methods of the object can still be called with the existing interface and is much more secure and efficient that resetting pointer to zero (it avoid testing objects for zero, I just call the object).

If a free like function say zfree(void * & p) would set p to zero it would forbid my watchdog style (or at least would'nt help).

And as others pointer out , what would be the point to reset a pointer to zero if it goes out of scope ? Just useless code. And what if there is other pointers that contain the same adress, etc.