Re: Referencing pointers after delete

Thread View: comp.std.c++

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Martin D Kealey Sun, 31 Mar 1996 15:12

#3873

Author: Martin D Kealey
Date: Sun, 31 Mar 1996 15:12

42 lines
2815 bytes

Tom Payne <thp@cs.ucr.edu> wrote:
> Steve Clamage (clamage@Eng.Sun.COM) wrote:
> : I don't see any advantage in trying to restrict the kind or form of checking
> : that systems are allowed to implement. I would applaud a hardware-based
> : mechanism, and I would resent a programming language standard that made
> : it non-conforming.
> The issue is not the form of the checking but the response to it.  The
> standard response to a hardware-detected fault is to invoke a signal
> handler, which is (or should be) completely conforming.

Consider this implementation with NO run-time pointer checking (as
is allowed) where every object contains not only a vtable pointer
but also an owner-task pointer as well, used for inter-process
memory management.

Now, if we run out of normal registers and it is necessary to
spill the "current task" register, its value can be reloaded
through any register pointing at an object (say because register-
indirect might be faster than absolute addressing). The compiler
writer knows this will only be done if a valid pointer value is
already in a register (and calling delete will invalidate the
register), since it would be more economical to obtain the value
some other way if a pointer to it isn't available).

However, using the value in an expression might cause a register
to get re-loaded with that value, so that reloading the task
pointer could go wrong; in a system with an unprotected memory
space, corrupting the task pointer could indeed be the equivalent
of "halt and catch fire".

Is there anything in such an implementation that is unconforming?
If not, then I submit that "undefined behaviour" IS the correct
term to apply to *any* use of an invalidated pointer value.

-Martin.

[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Re: Referencing pointers after delete

#3875

Author: Fergus Henderson
Date: Mon, 01 Apr 1996 04:11

32 lines
2363 bytes

martin@kcbbs.gen.nz (Martin D Kealey) writes:

[example implementation which can crash if a pointer is referenced
after the memory it points to has been deleted]

>Is there anything in such an implementation that is unconforming?
>If not, then I submit that "undefined behaviour" IS the correct
>term to apply to *any* use of an invalidated pointer value.

I don't think there is any disagreement about whether it IS undefined
behaviour; the question is about whether it should be.  Remember, every
instance in which the standard leaves the behaviour undefined is one
more hurdle for programmers trying to write portable programs.  I think
the possible efficiency gains from allowing optimizations such as the
one you described are likely to be very minimal even on those very rare
systems on which they might apply.  If that were the only reason, I
would think that it ought not be undefined behaviour.

However, the argument that the behaviour should be undefined in order
to support implementations which perform pointer validity checking in
hardware is more convincing.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads