🚀 go-pugleaf

In article 5vh@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>: You can't do anything useful in portable code with uninitialized pointers,
>: or pointers which point to objects which are no longer available. The
>: standard allows the implementation a great deal of leeway in trying to
>: help by identifying such invalid uses.
>
>.... just as for arithmetic exceptions, which also engender "undefined
>behavior."  But why the leeway to, say, reformat the disk, rather
>than specifying the normal practice, which is to invoke a signal
>handler, thereby, keeping the behavior defined?

Why should raising a signal be "normal practice"? Why not throwing an
exception? What about time-critical programs which would rather risk an
invalid pointer than pay the penalty of checking every pointer for validity?

If you specify the set of behaviors that are allowed when using an invalid
pointer, every pointer must be checked except those that can be proved at
compile time to be valid. If the runtime code does not check all the pointers,
there isn't any way to predict what will happen if you use an invalid  one.
(In general, that is. On specific platforms it might be possible, and the
degree to which it is specified is deemed a "quality-of-implementation"
issue.)

I don't know how to write a specification that says, "The implementation
doesn't have to check pointers, but invalid pointers aren't allowed to do
anything bad." I also don't know how to test an implementation for
conformance to such a rule.

The philosophical question here is how much validity checking should be
assured by the programming language. Should the implementation be required to
check for invalid pointers, arithmetic overflow, underflow, loss of precision?

Some languages have such requirements. Some C and C++ implementations do
indeed provide such checking. (The C and C++ definitions allow but do
not require those checks.) My observation is that such programming
languages and C/C++ implementations are not wildly popular. Maybe they
should be, but they are not. That seems to validate the decision to leave
those issues up to the implementation and its customers, in the sense that
many C and C++ programmers don't seem to care much about those things. 
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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                             ]