Talk:Dangling pointer

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer Security / Computing   
WikiProject icon This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.
 

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[edit]

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.

Some Confusion[edit]

"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.