Free () deletes data stored in dynamically allocated memory?

I wrote a simple program to check the contents of dynamically allocated memory after free () as shown below. (I know we shouldn't be able to access memory after free. I wrote this to check what will be in memory after free)

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

main()
{
    int *p = (int *)malloc(sizeof(int));

    *p = 3;
    printf("%d\n", *p);
    free(p);

    printf("%d\n", *p);
}

      

Output: 3 0

I thought it would print either the spam values ​​or a failure on the second print statement. But it always prints 0.

1) Does this behavior depend on the compiler?

2) if I try to free memory twice using free (), a core dump is generated. The manual pages mention that the behavior of the program is abnormal. But I always get a kernel dump. Does it also depend on the compiler?

+3


source to share


4 answers


Does it delete free()

data stored in dynamically allocated memory?

Not. free

just free the allocated space indicated by its argument (pointer). This function takes a char pointer to a previously allocated chunk of memory and frees it, that is, adds it to the list of free chunks of memory that can be reallocated.
Free memory is not cleared / erased in any way.

You must not dereference a freed (dangling) pointer. The standard says that:



7.22.3.3 Free function:

[...] Otherwise , if the argument does not match a pointer previously returned by memory management or if the space was freed by a call free

or realloc

, the behavior is undefined
.

The quote above also says that freeing the pointer twice will cause undefined behavior. When UB is in action, you can get either expected, unexpected results. There may be a program crash or a kernel dump.

+3


source


As described on the gnu website

Freeing a block changes the contents of the block. Don't expect to find any data (such as a pointer to the next block in the block chain) in the block after being freed.



Thus, accessing a memory location after freeing it results in undefined behavior, although the free does not modify the data in memory. U can get 0

garbage in this example, u can get garbage in another example as well.

And if you try to free memory twice, on the second try, you try to free memory that is not allocated, which is why you get a base dump.

+3


source


As for the C standard, it is simply not listed because it is not being observed. Once you have free

memory, all pointers pointing there are invalid, so there is no way to check that memory. *)

Even if you have the C standard library documenting certain behavior, your compiler may still assume that pointers aren't reused after being passed to free

, so you still can't expect any specific behavior.

*) I think even reading these pointers is UB, not just dereferencing, but it doesn't matter anyway.

0


source


In addition to all the no-use semantics explained above, you might actually want to research a lifesaver for every C programmer: valgrind. It will automatically detect such errors in your code and generally keep yours behind in the real world. The cover and all other static code checks are great too, but valgrind is awesome.

0


source







All Articles