Question about compilers and how they work

Question

This is the C code that frees memory of a singly linked list. It is compiled with Visual C++ 2008 and code works as it should be.

/* Program done, so free allocated memory */
current = head;
struct film * temp;
temp = current;
while (current != NULL)
{
    temp = current->next;
    free(current);
    current = temp;
}

But I also encountered ( even in a books ) same code written like this:

/* Program done, so free allocated memory */
current = head;
while (current != NULL)
{
    free(current);
    current = current->next;
}

If I compile that code with my VC++ 2008, program crashes because I am first freeing current and then assigning current->next to current. But obviously if I compile this code with some other complier ( for example, compiler that book author used ) program will work. So question is, why does this code compiled with specific compiler work? Is it because that compiler put instructions in binary file that remember address of current->next although I freed current and my VC++ doesn't. I just want to understand how compilers work.

Answer 1

The second program is invoking undefined behavior. It is not a difference in the compiler, but rather a difference in the implementation of the C standard library and the function free(). The compiler will store the pointer current as a local variable, but it will not store a copy of the memory that it references.

When you invoke free(), you give up ownership of the memory being pointed-to by the pointer passed to the free() function. It is possible that after you relinquish ownership, the contents of the memory pointed-to are still reasonable and are still valid memory locations in your process's address space. Consequently, it is possible that accessing them will appear to work (note that you can silently corrupt memory this way). A pointer that is non-null and points to memory that has already been relinquished is known as a dangling pointer and is incredibly dangerous. Just because it may appear to work does not mean it is correct.

I should also point out that it is possible to implement free() in such a way as to catch these errors, such as using a separate page per allocation, and unmapping the page when free() is called (so that the memory address is no longer a valid address for that process). Such implementations are highly inefficient, but are sometimes used by certain compilers when in debugging mode to catch dangling pointer errors.

Answer 2

After you do free(current), the memory pointed to by current (where current->next is stored) has been returned to the C library, so you shouldn't access it anymore.

The C library can change the contents of that memory at any time - which will result in current->next being corrupted - but it also might not change some or all of it, particularly so soon. That's why it works in some environments, and not others.

It's kind of like driving through a red traffic light. Sometimes you'll get away with it, but sometimes you'll be run over by a truck.