why dereferencing a C pointer after "free" gives value 0

Question

Below is the code:

#include <stdio.h>
#include <stdlib.h>
int main()
{
    int *p;
    p=(int *)malloc(sizeof(int));
    *p=5;
    printf("Before freeing=%p\n",p);
    printf("Value of p=%d\n",*p);
    //making it dangling pointer
    free(p);
    printf("After freeing =%p\n",p);
    printf("Value of p=%d\n",*p);
    return 0;
}

Below is the output:

Before freeing=0x1485010
Value of p=5
After freeing =0x1485010
Value of p=0

After freeing the pointer, dereferencing gives the output "0"(zero).

Below is another code that also gives '0'

include <stdio.h>
#include <stdlib.h>
int main()
{
int *p;
p=(int *)malloc(sizeof(int));

printf("Before freeing=%p\n",(void *)p);
printf("Value of p=%d\n",*p);
return 0;
}

In this i have not freed the memory , just allocated it , still it gives '0' . Is it like the default value of every uninitialized pointer is '0'??

why is it so ?

score 5 · Answer 1 · answered Oct 22 '13 at 16:20

5

Don't rely on this, it's undefined behaviour. free() doesn't have to set the pointer to zero, this is just what your current implementation is doing for you. If you want to be 100% sure, regardless of your compiler, platform, etc. set your pointer to NULL after freeing it.

answered Oct 22 '13 at 16:20

bstamour

7,746
1
26
39

1

In the OP, free() isn't setting the *pointer* to zero. – Andy Thomas Oct 22 '13 at 17:36

score 3 · Answer 2 · edited May 23 '17 at 11:51

This is simply undefined behavior if we look at the C99 draft standard Annex J.2 which covers undefined behavior says:

The behavior is undefined in the following circumstances:

and included the following bullet:

The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3).

Setting a pointer to NULL after free'ing is usually a good idea and you can find a good discussion here on that topic.

score 1 · Answer 3 · answered Oct 22 '13 at 16:22

1

Dereferencing an invalid pointer leads to undefined results per spec. It's not guaranteed to fail.

answered Oct 22 '13 at 16:22

Umer Farooq

7,356
7
42
67

glglgl · Answer 4 · 2013-10-22T21:20:12.233

While the answers "it doesn't matter, it is UB" are in general sufficient, one might be curious why the value changes. Curiosity is (IMHO) a valid reason to know the reason of why something happens.

It depends on the memory management which might decide to store addresses of the "next free block" or whatever in a freed memory area.

So what you observe is probably an action of the memory management.

For example, the memory management MIGHT be implemented in that way that it manages two linked lists and an upper pointer. One linked list contains the allocated memory chunks, pointing maybe 8 or 16 bytes before the "really usable" memory, and the other linked list points to the first free chunk, which in turn contains a pointer to the next one. The memory above the upper pointer is considered as free.

If you free the first memory block, the free list pointer points to it, and its first pointer sized data is zeroed, meaning that there is no other freed block. And there is your reason why the memory is zeroed out.

It is nice to know that things like these exist and how they work, but refrain the temptation to make use of that knowledge in production programs. One day they may fall onto your feet...

why dereferencing a C pointer after "free" gives value 0

4 Answers4