🚀 go-pugleaf

In article  <14340@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>...  Using C, with you 3-tuple
>idea, write the following routines: brk(), sbrk(), malloc(), and
>free().  You won't succeed.  This is because _at_least_one_ of these
>routines has to have direct explicit access to the internal representations
>of your 3-tuples (something has to be responsible for setting them).

The problem has not changed at all.  I wouldn't know how to write
those functions portably with "normal" pointers either unless (1)
there is a system function of some sort to tell me where to allocate
from (usually brk() or sbrk()) or (2) I declare my own array to
allocate from.  Either way, the code is identical for "normal"
pointers as for bounds-checked pointers.

Any code that has well-defined behavior with normal pointers has
exactly the same well-defined behavior with bounds-checked pointers.
If the semantics has changed at all, it is only in the sense that some
behavior that was previously undefined is now defined to produce an
error result.

>And I guess it's just a matter of taste that I consider:
>
>      for (i = 1; i < N-1; i++ )
>         for (j = 1; j < M-1; j++ )
>            A[i][j] = 0;
>
>is better than:
>
>      for (p = A; ???; ???)
>        /* Oh what the hell.  I don't feel like working it out.

Why do these multi-dimensional arrays keep popping up?  I don't think
anyone has said that pointers make a good indexing method for
multi-dimensioned arrays.  OK, I agree, pointers are not usually a
very good way to traverse multi-dimensional arrays.  That observation,
however has nothing to do with the larger question of whether it is
useful to have pointers (and pointer arithmetic) in a language.

Incidentally, you chose one of the few examples where I wouldn't mind
using pointers to traverse a multi-dimensional array:

  for (p = (t *)A; p < A + M * N; p++) *p = 0;

Of course, you should expect to loose a few points for "obscure code" on
your grade...
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman