S
Let's look at the code:#include <stdio.h>
#include <stdlib.h>
int main(void) {
int *ponteiro1 = malloc(sizeof(int));
*ponteiro1 = 5;
int *ponteiro2 = ponteiro1;
printf("%p == %p, %d == %d\n", (void *)ponteiro1, (void *)ponteiro2, *ponteiro1, *ponteiro2);
free(ponteiro2);
printf("%p == %p, %d == %d", (void *)ponteiro1, (void *)ponteiro2, *ponteiro1, *ponteiro2);
}
See https://ideone.com/jTY1GB . And https://repl.it/join/ntdikucw-maniero . Also https://github.com/maniero/SOpt/blob/master/C/Allocation/FreeAddress.c .It shows that the two variables have the same value, and that value is the pointer. We also see, of course, that the value contained in the allocated memory is the same when we melt the pointer and access the pointed object, after all if it is the same address in the variables then we certainly point to the same object. Nor could it be different, anywhere the code created 2 objects.If you consider that free() releases a memory address when it is released nothing else at that point should be used. The same way you allocated only once should release only once. There are no two allocations. The assignment of a variable in the other is not creating a new allocation. In C you have to be explicit in everything.Even if you try to release again you will have one https://pt.stackoverflow.com/q/173886/101 .It is important to note that the value of the variable is not zealous, you should not try to access this address after one free().Some people like to take care of the value of the variable to avoid unnoticed access. If you zeal and try to access then you will likely break the application which is better than working by coincidence and at another time go wrong without warning.If it was not clear, the value of the variable that is of the pointer type is never the value of the object, there are two completely distinct values in memory, this type always causes a https://pt.stackoverflow.com/q/181032/101 to access the real object.Zerating object valueWhat I found curious is that after free() the value of the object allocated in that address was considered 0. It gives the impression that the function free() Look at the value, but that's not about to happen. Of course the compiler is free to do whatever you want, but it would cost and C encourages not to put hidden costs that may not be necessary. In general, simple release will still allow access to the value of the object if nothing overwrites it.Researching a little seems that there is a case that the release of the application memory can release the memory to the operating system. This occurs when the address is not released to access by the application. Interestingly, it doesn't make a mistake and only accepts a neutral value. I got my hair up because it probably generates some cost. It doesn't mean that that's it, it might be that there's a change in the same value, you'd have to search his compiler or library to identify what he does.It may happen only in mode debug, what I do not like the idea because it changes the semantics of the code, can even hide a bug. It would make more sense because in this mode the performance is no problem, but it seems a bad solution.Looking https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c of the allocation may have occurred a medium term:struct malloc_chunk {
INTERNAL_SIZE_T prev_size; /* Size of previous chunk (if free). /
INTERNAL_SIZE_T size; / Size in bytes, including overhead. */
struct malloc_chunk* fd; /* double links -- used only if free. /
struct malloc_chunk bk;
/* Only used for large blocks: pointer to next larger size. /
struct malloc_chunk fd_nextsize; /* double links -- used only if free. /
struct malloc_chunk bk_nextsize;
};
A block of allocation may have overwritten in this situation the value of the object. This does not mean that it will always occur, but there has been a case that does not release into the operating system, but had an internal memory management processing that used memory inside the free().There I keep thinking that even the printf() could, in thesis, have done something that superscribed the value while he was processing the impression. I don't think it's good and I believe it's less likely. I do not remember this function to make an allocation in heap.
