🚀 go-pugleaf

From article <20079@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
> [...]
> OK, I'm confused.  I thought one of your objections to pointers was
> that they can point to undefined values, and that there was no way to
> do run-time error checking for this as is done for array indexes.

I never said so.  My objection to pointers is (and always has been) the
use of them when arrays are more appropriate.  Pointers _should_ be used
for things that arrays are _not_ suited to.  One instance of this is to
implement dynamic memory.  Here, it is the _purpose_ of the code to
return a reference to undefined values (undefined until allocation is
complete anyway).

Arrays are already bounded.  Why have two features with the same
functionality?

> [...]
> As to whether pointers _should_ obey bounds, it would be hard to
> justify any other interpretation.  [...]
> [...]          Any other interpretation would be either non-portable
> or force compilers on some machines to produce extremely poor code.

On any machine (even segmented ones) the memory model presented to
the user code is a contiguous memory address space.  It is within 
this linear address space that pointers should be free to roam.
(On virtual memory systems, the system may actually map the user's
memory allocation to discontiguous hardware memory locations.  But,
this is all invisable to the user code - or _should_ be.)

> [...]
> Are you suggesting that it would be an _advantage_ if pointers could
> be used like this?
> int foo()
> { int *p, i,j,k,l,m,n;
>   for (p = &i; p <= &n; p++) do_something(p);
> }
No.  I would not recommend such a thing.  Nor do I suggest using pointers
as a poor cousin of an array.  I want pointers to behave as addresses
within the linear address space presented to the user by the system.

J. Giles