[stdlib.h] free doesn't invalidate

[yoonkwun]

Hi, when I was checking if my cleanup function was working, I noticed that I could use allocated data even after calling free.

int main()
{
    short *a = 0;

    a = malloc(sizeof(*a));

    free(a);

    *a = 42;

    printf("%d", *a);

    return 0;
}

and would output 42. Does this mean that a was not truly freed?

[hamsterman]

no, this means, that a is a valid pointer that points to a memory location somewhere on your ram that your app has access to. freeing only means that now that location can be used by a newly allocated variable.

[imi]

no, this means, that a is a valid pointer that points...

Actually, many textbooks call these pointers "invalid pointer". ;-)

Accessing freed memory is "undefined behaviour" which basically means, the compiler is free to do what he likes (which is usually just access the old memory, but don't count on this. Some optimizations may reuse the memory quicker than you expect..)

[1yR4jE8b]

When you free memory, all it means is that the memory is free to be reallocated to somewhere else from that point on. It does not guarantee that dereferencing it gives you garbage data/segmentation fault etc...

That memory address will contain 42 until the program uses that memory again for another dynamically allocated variable.

[yoonkwun]

Thanks all. Another quick question, is there any real way to verify that the free function actually worked?

[Seraphimsan]

try reallocating the variable, and if it throws an error, catch it.

[Disch]

There have been some somewhat ambiguous responses to this question. I feel I should spell this out clearly:

    free(a);

    *a = 42;

This is HEAP CORRUPTION. You're writing to an invalid address (the address is no longer valid because the memory is freed).

If you're very lucky, this will crash to show you that something is horribly wrong. However more than likely you'll just corrupt the heap which is the worst kind of bug. It can make your program behave very strangely. These kinds of bugs are extremely difficult to find.

Never ever ever do this.

is there any real way to verify that the free function actually worked?

free always works.

[jsmith]

Another quick question, is there any real way to verify that the free function actually worked?

You should assume that functions do what they're supposed to do. It's impossible to write
software that has to defend against functions that don't work. At that point why would you
even assume that your compiler generates the correct machine code?

[1yR4jE8b]

Oh wow...I didn't even read his first post where he shows that he's dereferencing a free'd pointer.
I thought the pointer had 42 in it before he free'd it (lack of reading the actual code), and dereferenced it and wondered why it still had 42 in it.

Thanks for clearing that up Disch

[yoonkwun]

You should assume that functions do what they're supposed to do.

So you say that I should never check if malloc failed because I should assume that it does what it's supposed to do?

I didn't know that free "always worked" so I was asking if there was a method to check if it did work.

[Null]

I think it's a good idea to make pointers NULL so you can check if pointer is valid:

 free(a);
a=NULL;
//... lots of code
if(a!=NULL)   printf("%d", *a); 

[chrisname]

So you say that I should never check if malloc failed because I should assume that it does what it's supposed to do?

No. It does what it's supposed to do, which is attempt to allocate n bytes of memory on the heap. It is not malloc's fault if it can't allocate that memory for you. malloc fails when the operating system can't or won't give you more memory. It doesn't just fail for no reason.