Talk:Dangling pointer

Untitled

Wild pointers and dangling pointers are two different kind of errors, though they result in similar bug-patterns. This article warrants renaming or splitting therefore.

It depends and what you mean by "wild". "Wild" in this context usually applies to code that's gone amok. What value a pointer has is semantics only. Dr Roots (talk) 12:41, 16 July 2008 (UTC)

Redact

This seems to be a good article. It's certainly a topic that needs to be looked into as it's been discovered it's possible to attack a system in this way.

But the article itself needs to have its prose cleaned up. No doubt the original author knew what was going on but there are allegories here for things that are rather precise. Automatic (local) variables are not deallocated/freed on function call returns - they simply pass out of scope. Things like this need to be cleared up. It's important an author have a clear picture in mind - and stick to technically correct descriptions.

If the overwritten data is bookkeeping data used by the system's memory allocator, the corruption can cause system instabilities.

Editing to add (June 2024): The author sometimes claims to be giving “technically correct” information, but is actually giving misinformation. For example:

An all too common misstep is returning addresses of a stack-allocated local variable: once a called function returns, the space for these variables gets deallocated and technically they have “garbage values”.

It is not at all true that “technically [the variables] have ‘garbage values’”. *Technically*, it is undefined behavior to attempt to dereference such pointers at all; whether the memory they used to refer to contains “garbage values” or not is an implementation detail. Talking about “garbage values” might give readers the impression that it’s okay to access those values, but it might be unpredictable what they contain. But that is not the case at all. Actually, the behavior of the entire program is undefined, and it’s a mistake to think the values can be read from or used in any way.

Some Confusion

"As the system may reallocate the previously freed memory to another process, if the original program then dereferences the (now) dangling pointer, unpredictable behavior may result, as the memory may now contain completely different data."

This seems confusing. Any modern OS will provide each process its own virtual address space - in order to provide memory isolation between processes. There is no way a dangling pointer from one process can point into another process address space. True, the behavior is unpredictable, because the same process may reuse the memory, or the memory may not be mapped to physical memory anymore.

"If the overwritten data is bookkeeping data used by the system's memory allocator, the corruption can cause system instabilities."

The same goes here. Because of memory isolation a single process should not be able to cause system instabilities. It should not be able to break the memory allocator. Mhc (talk) 22:52, 21 November 2008 (UTC)

Hey what's up with this repetition!!!, Looks like trying to fill the page without adding extra info.

>Cause of dangling pointers

>The pointer still points to the same location in memory even though the reference has since been deleted and may now be used for other purposes.Dangling pointers and wild pointers in computer programming are pointers that do not point to a valid object of the appropriate type. These are special cases of memory safety violations. In many languages (e.g., the C programming language) deleting an object from memory explicitly or by destroying the stack frame on return does not alter associated pointers.

>The pointer still points to the same location in memory even though the reference has since been deleted and may now be used for other purposes. Dangling pointers and wild pointers in computer programming are pointers that do not point to a valid object of the appropriate type. These are special cases of memory safety violations. In many languages (e.g., the C programming language) deleting an object from memory explicitly or by destroying the stack frame on return does not alter associated pointers.>

>The pointer still points to the same location in memory even though the reference has since been deleted and may now be used for other purposes.