Michael Milgram writes:
> "A pointer's association status is one of
>
> undefined (initial state);
> associated (after allocation or a pointer assignment);
> disassociated"
>
> In Metcalf and Reid, a further distinction is made for the case of an
> associated pointer whose target is deallocated - they refer to this
> case as a "dangling" pointer.
The term "dangling" pointer is just a particular case of a pointer
whose association status is undefined. It isn't a 4th case.
> 2. Lahey technical support maintains that "Any reference to a dangling
> pointer will produce an unpredictable result", implying that a program
> crash is allowable. Does the standard say anything about this?
Definitely. That is exactly what the standard says. It is a bug in
your program if you ever reference an undefined pointer or do much of
anything with it. It is *NOT* something that is up to the compiler to
catch - it is up to you to avoid.
> 3. Is there any approved way to test for a "dangling" pointer within the
> standard?
No. Nor to test for pointers with undefined association state.
Indeed, that's the whole point. Being undefined is not necessarily
a property that has a physical manifestation in the computer at all.
It is more a concept of the standard than of what you can find in
the computer. When the standard says something is undefined that
means that any use of it can give unpredictable results - that is
exactly the meaning of the term. If this was some measurable
state of a pointer, then the pointer would be defined to have that
state...which then wouldn't be undefined.
Note that little of this is really any different at all from the way
that plain old ordinary nonpointer variables may be undefined (and
indeed start out that way unless they are initialized). It is illegal
to reference an undefined variable, and you can't even test whether or
not a variable is defined. You just have to know. If you violate
this, then anything may happen. The "anything" quite realistically
can include 1) being zero 2) being the same as it was some time in the
past 3) being some random value 4) having a special "flag" value like
a NaN, 5) causing the program to abort 6) causing strange hardware
effects (if the variable is mapped onto a hardware device address).
Every one of these cases actually happens in real systems; these
aren't just theoretical. I've probably even left out some.
> 4. Is my understanding correct that the first DEALLOCATE statement in
> the second example BOTH deallocates the target of ELEMENT1 (in this case
> the pointer ELEMENT), AND disassociates the pointer ELEMENT1?
Yes.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|