Is It Legal to Compare Dangling Pointers

Dangling pointers

A dangling pointer is a pointer that points to a location in memory where there was an object but that object is already gone.

A dangling pointer is nothing useful or desirable, it rather describes that the pointer is completely useless and you probably have a logic error in your code.

Consider this:

int* x;
{ 
    int y = 4;
    x = &y;
}
*x = 42;   // BOOOM !! Dont do this !! Undefined behavior !!

After closing the scope (}) the object x points to does no longer exists. x will not automagically be set to NULL or anything the like. There is no y at the memory location x was pointing to. The official terminology is that after closing the scope x has a invalid pointer value in C++ and in C the value of the pointer is indeterminate.

On the other hand, if you do not dereference x after y is gone, there is no problem. x is still a dangling pointer but you can simply assign something else to make it point to some object again:

int* x;
{ 
    int y = 4;
    x = &y;
}                 // <- x can be said to be dangling here, but who cares?
int z = 5;
x = &z;           // <- x again points to an object

What is the difference between a dangling pointer and memory leak?

What is the difference between a dangling pointer and memory leak?

You could say a dangling pointer is the opposite of a memory leak.

One is a pointer that doesn't point to valid memory, and one is valid memory that nothing points to.

(But as the other answers point out, your code is neither.)

Is it safe to compare to pointer of std::vector to check equality?

std::vector<int> vec;
vector<int>* pVec = &vec;
vec.reserve(10000);
assert(pVec == &vec);

is safe.

---

std::vector<int> vec(1,0);
int* p = &vec[0];
// some operation here
assert(p == &vec[0]);

is not safe.

---

The first block is safe since the address vec will not change even when its contents change.

The second block is not safe since the address of vec[0] may change; for example when the vec resizes itself — e.g, when you push_back elements to it.

Is it ok to use a pointer which point to the address of a variable declared inside if statement

The problem is the life span of the pointer is greater than that of the object pointed to. This smells bad and you should rethink what you're trying to do.

Difference between dangling pointer and memory leak

A dangling pointer points to memory that has already been freed. The storage is no longer allocated. Trying to access it might cause a Segmentation fault.

Common way to end up with a dangling pointer:

char *func()
{
   char str[10];
   strcpy(str, "Hello!");
   return str; 
}
//returned pointer points to str which has gone out of scope. 

You are returning an address which was a local variable, which would have gone out of scope by the time control was returned to the calling function. (Undefined behaviour)

Another common dangling pointer example is an access of a memory location via pointer, after free has been explicitly called on that memory.

int *c = malloc(sizeof(int));
free(c);
*c = 3; //writing to freed location!

---

A memory leak is memory which hasn't been freed, there is no way to access (or free it) now, as there are no ways to get to it anymore. (E.g. a pointer which was the only reference to a memory location dynamically allocated (and not freed) which points somewhere else now.)

void func(){
    char *ch = malloc(10);
}
//ch not valid outside, no way to access malloc-ed memory

Char-ptr ch is a local variable that goes out of scope at the end of the function, leaking the dynamically allocated 10 bytes.

What is the difference between garbage and dangling references?

A dangling reference is a reference to an object that no longer exists. Garbage is an object that cannot be reached through a reference.

Dangling references do not exist in garbage collected languages because objects are only reclaimed when they are no longer accessible (only garbage is collected). In some languages or framework, you can use "weak references", which can be left dangling since they are not considered during collection passes.

In languages with manual memory management, like C or C++, you can encounter dangling pointers, by doing this for instance:

int * p = new int;
delete p;

int i = *p; // error, p has been deleted!

Does comparing a pointer that has been free'd invoke UB?

Using a value of a pointer after the object it is pointing to have reached it's lifetime end is indeterminate as stated in the C11 Standard draft 6.2.4p2 (Storage durations of objects) (the emphasis is mine):

The lifetime of an object is the portion of program execution during
which storage is guaranteed to be reserved for it. An object exists,
has a constant address, and retains its last-stored value
throughout its lifetime. If an object is referred to outside of its
lifetime, the behavior is undefined. The value of a pointer becomes
indeterminate when the object it points to (or just past) reaches the
end of its lifetime.

And using it's value (just for anything) is an explicit undefined behavior as stated in Annex J.2(Undefined behavior):

The behavior is undefined in the following circumstances: [...] The
value of a pointer to an object whose lifetime has ended is used
(6.2.4).

---

Related Topics