Editing Dangling pointer (section)

==Avoiding dangling pointer errors==

In C, the simplest technique is to implement an alternative version of the <code>free()</code> (or alike) function which guarantees the reset of the pointer.  However, this technique will not clear other pointer variables which may contain a copy of the pointer.

<syntaxhighlight lang="c">
#include <assert.h>
#include <stdlib.h>

/* Alternative version for 'free()' */
static void safefree(void **pp)
{
    /* in debug mode, abort if pp is NULL */
    assert(pp);
    /* free(NULL) works properly, so no check is required besides the assert in debug mode */
    free(*pp);                  /* deallocate chunk, note that free(NULL) is valid */
    *pp = NULL;                 /* reset original pointer */
}

int f(int i)
{
    char *p = NULL, *p2;
    p = malloc(1000);    /* get a chunk */
    p2 = p;              /* copy the pointer */
    /* use the chunk here */
    safefree((void **)&p);       /* safety freeing; does not affect p2 variable */
    safefree((void **)&p);       /* this second call won't fail as p is reset to NULL */
    char c = *p2;       /* p2 is still a dangling pointer, so this is undefined behavior. */
    return i + c;
}
</syntaxhighlight>

The alternative version can be used even to guarantee the validity of an empty pointer before calling <code>malloc()</code>:

<syntaxhighlight lang="c">
safefree(&p);        /* I'm not sure if chunk has been released */
p = malloc(1000);    /* allocate now */
</syntaxhighlight>

These uses can be masked through <code>#define</code> directives to construct useful macros (a common one being <code>#define XFREE(ptr) safefree((void **)&(ptr))</code>), creating something like a metalanguage or can be embedded into a tool library apart. In every case, programmers using this technique should use the safe versions in every instance where <code>free()</code> would be used; failing in doing so leads again to the problem. Also, this solution is limited to the scope of a single program or project, and should be properly documented.

Among more structured solutions, a popular technique to avoid dangling pointers in C++ is to use [[smart pointer]]s. A smart pointer typically uses [[reference counting]] to reclaim objects. Some other techniques include the [[tombstone (programming)|tombstones]] method and the [[locks-and-keys]] method.<ref name="Fisher" />

Another approach is to use the [[Boehm garbage collector]], a conservative [[garbage collection (computer science)|garbage collector]] that replaces standard memory allocation functions in C and [[C++]] with a garbage collector. This approach completely eliminates dangling pointer errors by disabling frees, and reclaiming objects by garbage collection.

Another approach is to use a system such as [[Capability Hardware Enhanced RISC Instructions|CHERI]], which stores pointers with additional metadata which may prevent invalid accesses by including lifetime information in pointers. CHERI typically requires support in the CPU to conduct these additional checks.

In languages like Java, dangling pointers cannot occur because there is no mechanism to explicitly deallocate memory. Rather, the garbage collector may deallocate memory, but only when the object is no longer reachable from any references.

In the language [[Rust (programming language)|Rust]], the [[type system]] has been extended to include also the variables lifetimes and [[resource acquisition is initialization]]. Unless one disables the features of the language, dangling pointers will be caught at compile time and reported as programming errors.