Malloc, Free and OS role
 

Hi

#include <stdio.h>

void main()
{
..........
............
int *b = (int*)malloc(10);
free(b);
b = NULL; ////See Here
..............
...........
}

Now, I have a doubt that what is the importance of the last statement (b = NULL).... I think that this is rigorous coding and prevents from accessing memory which should not be accessed by program.
Then I think if it is so what the hell OS and Compiler will do for memory management....

Please tell me to include the last statement in the code is worth good or it is non-useful.

P.S... If you include the last statement and run the code on win platform... It will not run longer if I access "b" later... If I dont include the last statement, it rund quite a longer... Not checked in Linux though...

IMHO this is defensive programming. If you have the habit to check a pointer for being non-null before it is used, with setting it to NULL you make it clear no memory is allocated.

If you omit setting it to NULL or you don't check on it being NULL, chances are you use a pointer to non-allocated memory.

If you don't make any errors anywhere, you program runs just fine. However most of us do make errors.

If your program gets larger, and does a lot of freeing and allocating, I think it is a good practice to set a pointer to NULL.

jlinkels

jlinkels is right. The main benefit of setting the variable "b" to (what I assume is) 0x0 after you free it is that later accidental accesses to an unallocated "b" will result in a SIGSEGV. Having your program crash with a consistent, and therefore easier to debug, behaviour is much better than reading / writing other unknown memory in your address space.

Echoing what has been said, leaving dangling pointers is not only a bad thing, its very dangerous as well.

Other programs may later allocate memory from that space while you're executing, and your variable (b) will allow your program to change that memory without proper permission. Sure, most desktop OSes include segmentation and virtual memory to protect us against this, but many embedded OSes are not as defensive.

ALWAYS make sure that you cleanup dangling pointers after you've freed memory. The consequences of not cleaning memory are way too dangerous.

It might be a good idea to have a macro that you can use to call free, and automatically set the pointer to null. It's a good way to ensure that every pointer is returned to 0.

I agree: initializing pointers to NULL when you declare them, and then setting them to NULL after you free them is excellent programming practice!

The sad irony is that it's usually those programmers who DON'T follow this practice ... who would really benefit the most ;-)

Warning about initializing pointers to 0 religiously: If the next statement is going to assign something else to the pointer, it is easier and clearer (to me) to just initialize it to the something else in the first place. It will not compromise defensive programming. If you are writing a destructor for a struct and that frees the pointers inside, it is fairly safe not to assign those pointers to 0, since the lifetime of the dangling pointer is known to be small.

That said, anything done religiously is bad, so no surprise there.