Wild Pointer

A pointer that doesn't point to either a valid object (of the indicated type, if applicable), or to a distinguished null value, if applicable. (In CeeLanguage/CeePlusPlus, pointers one element past the end of an array are legal but not dereferenceable; they are very similar to NullPointers in this regard).

WildPointers can be broadly categorized with respect to time-related behavior in exactly 4 ways; pointer value is invalid because: The above list is exactly 4 items because it covers all of the relevant possibilities with regard to time (never, past, current, future). (This is my own analysis, not something I found in the literature, so by all means let me know if I overlooked some possibility. -- dm)

Lists of general causes can be arbitrarily large.

Those invalid conditions in turn can be caused by (among many, many possibilities):

WildPointers are never truly a good thing long term, although they have been known to accidentally produce desirable behavior in the short term. They often lead to HeisenBugs, SchroedinBugs, MandelBugs, etc., e.g. when a WildPointer accidentally initializes an otherwise-uninitialized variable, causing the program to work -- until a different compilation option is used, or some new code/data is added, or old code/data changed/modified, or until the program is run under the IDE/debugger -- and then the WildPointer overwrites something less beneficial because the location of things in RAM gets shifted around, and the code stops working, or a more severe problem comes up, etc.

Many languages attempt to (and some succeed at) eliminating WildPointers by:


Y'know, ultimately you can't legislate against accidents. At some point the programmer has to be responsible for what he writes. Removing a powerful mechanism from a language (or group of languages) on the grounds that some people have accidents with it is an abdication of responsibility. They pay us more because we (supposedly) have the skill and wisdom not to point guns at our own feet.

At some level of the programming stack (near the bottom), PointerArithmetic is unavoidable. Perhaps it is always generated by a compiler; but all the high-level constructs that we use ultimately boil down to operations on the fundamental machine types--ints, floats, and addresses (give or take a few).

On the other hand, at sufficiently high levels of abstraction, it becomes more of a liability than an asset.

You can add overheads to the compiler and/or the runtime environment to "keep us safe" from all the vagaries of the human mind, but every one of these "safeguards" exacts a price.

Yes, WildPointer is a bad thing, but alertness of the programmer would seem to be a better idea than YetAnotherSeatBelt? at runtime.

This is becoming less true every day; thanks to MooresLaw.

Do you mean to say that the price is no longer there?

Depends on the application. For CrudScreens, shell scripts, and numerous other types of programs; the price is sufficiently inexpensive that it shouldn't be a design concern. For high-performance applications, systems programming, etc., the price is still significant.

Use the language(s) and technique(s) appropriate for your application. That advice has always been sound.
Wild Pointers Are A GoodThing

By the definition of "Wild Pointer" above, a wild pointer is a necessary condition. There are reasons to have a pointer to an invalid object.

Please note that GarbageCollection does not completely solve the problem of memory management. It replaces the problem of early deallocation of memory (and pointers to invalid memory locations) with the problem of late or non-existent deallocation of memory (and memory leaks).

If one has two "owners" of a single object, there are lots of data change issues. Double deallocation is only one of them. -- AnonymousDonor

And GarbageCollection does not lead to MemoryLeaks. The purpose of a heap allocator is to make sure a free block of memory can always be allocated upon request. A garbage collector simply frees unused memory whenever a memory request would otherwise fail (or frees a bit with each allocation, for IncrementalGarbageCollection?). The programmer cannot tell the difference. Resource leaks are another concern, and a known problem with garbage collectors, but that's beyond the scope of this page. -- JonathanTang
See DanglingPointer
CategoryPointer

EditText of this page (last edited November 8, 2014) or FindPage with title or text search