🚀 go-pugleaf

In article <4869@vanuata.cs.glasgow.ac.uk> jack@cs.glasgow.ac.uk
(Jack Campin) writes:

>> Can anyone clue me as to the basis for pointer paranoia?
>
>Garbage collection, for one.  If you try to implement a BCPL-family
>language on a machine/OS with garbage-collected object memory [i.e. a
>storage model a bit more sophisticated than a Turing machine], you have
>real problems identifying what objects are still being referenced when
>pointers can be incremented.

	But pointers can't be incremented off the current object, so
the problems are exactly the same for C and Pascal and any other language
for which this is a problem at all.  Object-bounds checking in C is
exactly as hard or easy as array-bounds checking in other languages, so
is often "switched off", but that's a different matter.  Or are you
talking about the inherent insecurities of the "malloc ... free" model
of heap storage?  If so, this again applies to Pascal, but not to other
languages with proper heap mechanisms.  In any case, it's a solved
problem.

>Secondly, real machines are sufficiently different from the Turing tape
>that the result of a pointer arithmetic operation is not merely wordsize-
>dependent like normal computer "arithmetic", it's OS-dependent.  Or do C
>fans think it's a good idea to have operator semantics vary with the host
>segmentation scheme?

	I don't understand this either.  There is no interesting difference
between
		pa = pa + 5;	/* pa points into an array */
and
		j = j + 5;	/* j is being used as an index */

except that if the index or pointer is now illegal, the pointer may be
detected instantly whereas the index can't be caught until it is next
used.  One up to pointers?  (If j is a ranged type, the error may then
also be caught here, but that's a less flexible solution.)

>Thirdly, the aliasing it enables is a semantic mess.  If anyone claims
>different, let's see your denotational model of ANSI C.

	Well, I hate denotational semantics, so no offers, but again I
don't understand the problem.  Yes, aliassing is a problem for optimising
compilers, and if used casually is a problem for program-proving;  but
exactly the same problems arise with arrays, so this isn't a pointer
problem, even less a pointer arithmetic problem.

	Summary:  the question was about pointers, but the answers seem
to apply to any aliasable or indexable construction, and we're not yet
being told that C/Pascal/Fortran/whatever shouldn't have arrays.  Or are
we?  Or am I missing Jack's point?

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk