C Programming - Pointers

If you free a pointer, use it to allocate memory again, and free it again, of course it's safe

If you free a pointer, the memory you freed might be reallocated. If that happens, you might get that pointer back. In this case, freeing the pointer twice is OK, but only because you've been lucky. The following example is silly, but safe:

#include <stdlib.h>
int main(int argc, char** argv)
{
        char** new_argv1;
        char** new_argv2;
        new_argv1 = calloc(argc+1, sizeof(char*));
        free(new_argv1);    /* freed once */
        new_argv2 = (char**) calloc(argc+1, sizeof(char*));
        if (new_argv1 == new_argv2) 
        {
                /* new_argv1 accidentally points to freeable memory */
                free(new_argv1);    /* freed twice */
        } 
        else 
        {
                free(new_argv2);
        }
        new_argv1 = calloc(argc+1, sizeof(char*));
        free(new_argv1);    /* freed once again */
        return 0;
}

In the preceding program, new_argv1 is pointed to a chunk of memory big enough to copy the argv array, which is immediately freed. Then a chunk the same size is allocated, and its address is assigned to new_argv2. Because the first chunk was available again, calloc might have returned it again; in that case, new_argv1 and new_argv2 have the same value, and it doesn't matter which variable you use. (Remember, it's the pointed- to memory that's freed, not the pointer variable.) new_argv1 is pointed to allocated memory again, which is again freed. You can free a pointer as many times as you want; it's the memory you have to be careful about.

What if you free allocated memory, don't get it allocated back to you, and then free it again? Something like this:

void caller( ... )
{
        void *p;
        /* ... */
        callee( p );
        free( p );
}
void callee( void* p )
{
        /* ... */
        free( p );
        return;
}

In this example, the caller() function is passing p to the callee() function and then freeing p. Unfortunately, callee() is also freeing p. Thus, the memory that p points to is being freed twice. The ANSI/ ISO C standard says this is undefined. Anything can happen. Usually, something very bad happens.

The memory allocation and deallocation functions could be written to keep track of what has been used and what has been freed. Typically, they aren't. If you free() a pointer, the pointed-to memory is assumed to have been allocated by malloc() or calloc() but not deallocated since then. free() calculates how big that chunk of memory was and updates the data structures in the memory "arena." Even if the memory has been freed already, free() will assume that it wasn't, and it will blindly update the arena. This action is much faster than it would have been if free() had checked to see whether the pointer was OK to deallocate.

If something doesn't work right, your program is now in trouble. When free() updates the arena, it will probably write some information in a wrong place. You now have the fun of dealing with a wild pointer;

NULL is a macro defined in <stddef.h> for the null pointer.

NUL is the name of the first character in the ASCII character set. It corresponds to a zero value. There's no standard macro NUL in C, but some people like to define it.

NULL can be defined as ((void*)0), NUL as '\0'. Both can also be defined simply as 0. If they're defined that way, they can be used interchangeably. That's a bad way to write C code. One is meant to be used as a pointer; the other, as a character. If you write your code so that the difference is obvious, the next person who has to read and change your code will have an easier job. If you write obscurely, the next person might have problems.

These are all serious errors, symptoms of a wild pointer or subscript.

Null pointer assignment is a message you might get when an MS-DOS program finishes executing. Some such programs can arrange for a small amount of memory to be available "where the NULL pointer points to" (so to speak). If the program tries to write to that area, it will overwrite the data put there by the compiler. When the program is done, code generated by the compiler examines that area. If that data has been changed, the compiler-generated code complains with null pointer assignment.

This message carries only enough information to get you worried. There's no way to tell, just from a null pointer assignment message, what part of your program is responsible for the error. Some debuggers, and some compilers, can give you more help in finding the problem.

Bus error: core dumped and Memory fault: core dumped are messages you might see from a program running under UNIX. They're more programmer friendly. Both mean that a pointer or an array subscript was wildly out of bounds. You can get these messages on a read or on a write. They aren't restricted to null pointer problems.

The core dumped part of the message is telling you about a file, called core, that has just been written in your current directory. This is a dump of everything on the stack and in the heap at the time the program was running. With the help of a debugger, you can use the core dump to find where the bad pointer was used.

That might not tell you why the pointer was bad, but it's a step in the right direction. If you don't have write permission in the current directory, you won't get a core file, or the core dumped message.

The same tools that help find memory allocation bugs can help find some wild pointers and subscripts, sometimes. The best such tools can find almost all occurrences of this kind of problem.

You can't, really. free() can, but there's no way for your program to know the trick free() uses.