🚀 go-pugleaf

In article  <16777@snow-white.udel.EDU> new@udel.EDU (Darren New) writes:
>In article <20197@megaron.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>>[implementing malloc() with 3-tuple pointers]
>
>Except that you lose the bounds checking in the array case.  I.e., if
>you malloc(50) and then access element 52, as long as it is within your
>static array you won't get any violation.  Also the case with sbrk()
>uless you can somehow set the bounds.

Lets try to gain some perspective here.  The whole 3-tuple thing
started because Jim Giles was stomping on C's pointer arithmetic and one
of his alleged criticisms was that pointers that access arrays could
not be bounds checked, and were therefore inherently less "safe" than
indexes.  The 3-tuple technique was proposed to show that this
argument is wrong.

Now, since that has been disposed of, Jim has retreated to the
position that 3-tuple pointers are not as general as regular pointers.
How this relates to the use of pointers-instead-of-indexes is beyond
me, since the bounds checking was only intended to answer that single
criticism.  Even so however, the assertion was wrong, and I pointed it
out.

Now someone points out that a malloc() implemented in a C with bounds
checked pointers will not return bounds checked pointers (except
possibly that pointers will be bounded to the whole region).  What
does this have to do with either (1) pointers-instead-of-indexes or
(2) whether the semantics of bounds-checked pointers is compatible
with the semantics of unchecked pointers?  What can I say except (1)
try to implement malloc() with arrays and indexes to get
bounds-checked pointers (or indexes) and (2) the malloc() implemented
with 3-tuple pointers has the same semantics as the malloc()
implemented with unchecked pointers.

If you want malloc() to return bounds-checked pointers, you obviously
can't implement it entirely in C, whether or not the C pointers are
bounds checked.

>>>      for (i = 1; i < N-1; i++ )
>>>         for (j = 1; j < M-1; j++ )
>>>            A[i][j] = 0;
>>  for (p = (t *)A; p < A + M * N; p++) *p = 0;
>
>These two are not identical.  Note that the array-case does not clear
>the "outside edge" (0 or N) of the array (assuming that is what was meant).

I didn't notice the array bounds.  So I wouldn't use a pointer in this
case, I would use array indexes.  As I've said before, there are some
jobs that are better done with arrays and some jobs that are better
done with pointers.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman