5

Possible Duplicate:
Should one really set pointers to NULL after freeing them?

I have allocated dynamic memory to pointer using malloc and calloc. After using this pointer, I should free the memory so that block can be returned to OS(its fine). Now My question is that after freeing the block, why should I do something like that:

pointer = NULL;

Thanks for help...

Community
  • 1
  • 1
Sandeep Pathak
  • 10,567
  • 8
  • 45
  • 57
  • 4
    possible duplicate of [Should one really set pointers to `NULL` after freeing them?](http://stackoverflow.com/questions/1879550/should-one-really-set-pointers-to-null-after-freeing-them). Also see: [Setting variable to NULL after free](http://stackoverflow.com/questions/1025589/setting-variable-to-null-after-free) and [Is it always a good practice to set pointers to NULL after free()-ing them?](http://stackoverflow.com/questions/3365772/is-it-always-a-good-practice-to-set-pointers-to-null-after-free-ing-them), among others. – Cody Gray - on strike Feb 01 '11 at 10:59

4 Answers4

8

So that we don't leave dangling pointers behind. Without nulling out unused pointers, you have no way to detect later whether the pointer can be safely dereferenced or freed. And attempting to dereference or free a dangling pointer results in undefined behaviour ( = crash).

Péter Török
  • 114,404
  • 31
  • 268
  • 329
  • 1
    It crashes only if you're lucky. The worst part is that program usually survives, but it becames very difficult to find the bug in code. – ruslik Feb 01 '11 at 23:48
  • 1
    @ruslik, indeed. Although eventually it will (almost always) crash nonetheless. I just wanted to give a simple explanation for the OP :-) – Péter Török Feb 02 '11 at 08:14
3

Because if you try to free() it again Undefined Behaviour will occur.

Also, note that after free-ing, the memory is reclaimed by the program. not the OS. The memory is reclaimed by the OS, after the execution of the program has ended.

2

If the pointer variable remains in scope you can't later find whether it stores a valid address or not and if you try to use that pointer you run into undefined behavior.

Setting a pointer to null after free() is a protection measure. You don't need this if you know that the pointer will get out of scope soon after free():

if( ... ) {
    void* ptr;
    ptr = malloc( ... );
    //use the buffer;
    free( ptr );
    ptr = 0; //not actually needed
}

but at the same time most compilers will see that in such case setting a pointer to null has no observable effect and optimize that code away.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
1

It is better because :

First, it makes your code simpler. When you manage memory, you do malloc and free a lot of time. If you set it to NULL you can do things like :

int *pMyInteger;

/* in init code */

pMyInteger = (int *) malloc(42);

/* use pMyInteger */

free(pMyInteger);
pMyInteger = NULL;

/* somewhere else you have to change the size */

free(pMyInteger);
pMyInteger = (int *) malloc(42 * 10000);

It's really easier, no ?

Second, it is easier too to spot a NULL (0) pointer in the debugger than a dangled one. It easy to guess that there is a pointer management problem when you see 0x0 in the debugger.When you see 0xbac765, it's harder :)

my2c

neuro
  • 14,948
  • 3
  • 36
  • 59