🚀 go-pugleaf

Steve Clamage (clamage@Eng.Sun.COM) wrote:
[...]
: There isn't any way to predict in a platform-independent way what the
: range of responses might be to using an invalid pointer, so the choices

The issue is whether one can specify an efficient, reasonable,
platform-independent response.  In general, it depends on the use.
For instance, Accessing the (pseudo)object obtained by dereferencing
an invalid pointer will produce such a range of possibly bizarre
results that there is visibly no way to specify.  But we are
considering the matter of reading a pointer to an deleted
object.

: boil down to requiring implementations in general to detect invalid
: pointers at run time, or not requiring them to detect invalid pointers.

I know of no acceptably efficient platform-independent mechanism for
detection.

: In my view, a requirement like "must raise a signal" as the response is
: no better than requiring any other particular behavior. On some systems

So, make the signal optional.  In any case, let processing continue 
with the standard-specified contract between the running program and
the implementation in force at least until something serious happens,
like a derefercing of the invalid pointer.

: raising a signal is the default hardware response and comes for free.
: Other systems have no hardware detection or a different hardware
                                           ^^^^^^^^^^^^^^^^^^^^^^^^
: response, so run-time checks would be required to avoid unpredictable or
  ^^^^^^^^
This is probably the hub of our difference: I have difficulty
imagining a reasonable architecture that does something other than
ignoring or trapping the reading of invalid pointers.  (Granted,
"reasonable" is in the eye of the beholder.)

: disallowed behavior. Loosening the requirement to "must raise a signal,
: or do A or do B or do C" doesn't change the general case. What if some
: platform, such as a system to be built years from now, normally reacts
: by doing D?

There is no way of knowing how some furture architecture might respond
to any operation, not jut that of the reading of invalid pointers.

The argument that we need to open up all possible options in response
to the detection of an invalid value misses the point that a signal
handler, invoked upon detection of such a value, can generate whatever
behavior the programmer pleases including a call to abort.  (Note that
this puts the programmer, not the implementor in control of that
response, which is as things should be IMHO.)

The real problem, inherited from C, is that in the standard specifies
"undefined behavior" whenever an operation on a valid object might
yield an indeterminate or invalid value, e.g., reading a pointer
object to a deleted object or reading a global variable from a signal
handler.  The contract between the running program and the underlying
implementation is voided even if the program never uses that value.
The common rationale is that such a value can never be put to good use
(e.g., dereferencing the invalid pointer value will yield undefined
behavior anyway), but one might, for instance, cast an invalid pointer
to an integer and print it out for diagnostic purposes.  (In the case
of signal handlers, one can implement locks and signal blocking on the
basis of those indeterminate values.  How else do we handle such
things in assembly language?)

I would like the standard to specify that control stays with the
programmer, whenever it is reasonable to do so.  When the standard
says "undefined behavior" such control is lost.

Tom Payne (thp@cs.ucr.edu)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]