🚀 go-pugleaf

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                             ]