Jump to content

Talk:Dangling pointer

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Mhc (talk | contribs) at 22:53, 21 November 2008. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

Null pointers as dangling pointers?

I've never seen null pointers being referred to dangling pointers. I'm not familiar with the term wild pointer - does those include null pointers? I suggest to remove this part ", or to a distinguished null pointer value in languages which support this" in the introduction.

Yet another reason to do this is that the article currently contradicts itself by "dedangling" pointers by setting them to null. Bajsejohannes (talk) 11:32, 7 January 2008 (UTC)[reply]

According to c2, a dangling pointer is a special case of a wild pointer. A null pointer is not a dangling pointer, but it is a wild pointer. I'll try to clean up this article some time... Bajsejohannes (talk) 12:58, 10 January 2008 (UTC)[reply]

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.

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)[reply]