Out-of-bounds pointers

[John Bruner]

It is possible for a machine to push a register containing a bad
pointer onto the stack as part of a procedure call and STILL treat
the use of a bad pointer in user-written code as an error causing a
fault.  The former is an internal operation, while the latter is
user-specified.  To cite another example, presumably the operating
system will not incur a fatal error if it tries to store a bad
user pointer during a context switch.  A machine which performs
type checking in hardware may have some instructions which move
data around in an unchecked fashion, but for maximum runtime type
checking the compiler should generate pointer move instructions for
user-specified pointer operations rather than generic move
instructions.  In addition, is less likely that such a machine
would have an untyped compare than that it would have a simple
untyped move, load, or store.

The S-1 Project at the Lawrence Livermore National Laboratory built
two machines with various degrees of tagged data.  Pointers were not
the same as integers, and the hardware would detect mixing of data
types and cause faults.  One of the machines also provided hardware-
implemented segmentation, so that pointers had to lie within the
valid range of a segment or a trap would occur.

The pANS definitions for pointers make it possible to implement C
on machines that don't resemble the vanilla machines which dominate
the market today.  The warning that it isn't portable is just
that -- a warning.  The same could be said for programs that always
use "int" when they should use "long".  The VAX/Sun/MIPS/whatever
will let you do it, and your program will run on a lot of machines,
but it isn't portable if you store values which are too big or call
routines which expect long arguments (assuming no prototype is in
scope).
--
John Bruner	Center for Supercomputing R&D, University of Illinois
	bruner at uicsrd.csrd.uiuc.edu	(217) 244-4476