Pointers and Arrays

[Wayne Throop]

Several interesting points are raised about just what is the difference
between a pointer to an array, and a pointer to the first element of an
array.

> jsdy at hadron.UUCP (Joseph S. D. Yao)
> I have seen several references to the address of an array vs.
> the address of the first element of the array.  Would someone
> care to address what they think this difference is, aside from
> data type?  I.e., it is clear that the types *int and *(int[])
> should be different.  But the values should be the same:

What is really the case is that the first addressable element of the
array is the same as the first addressable element of the first element
of the array.  (This is not true in all languages, but must be so in C,
unless I'm overlooking something quite tricky.)

But one *MUST* keep in mind that this is *NOT* the same thing as saying
that the bit patterns of these pointers must be the same.  Nor is it
meaningful to say that "they have the same value".  The most one should
say is that they have the same bit-pattern on most common architectures.

Consider an analogous argument.  "I have seen several references to
floating point zero vs integer zero.  It is clear that the types (float)
and (int) should be different.  But the values should be the same."
(And, just as the two pointers above are "really" indicating the same
storage element, the two values are "really" indicating the same point
on the "number line".)

Most people see that this is bogus (I hope). And it is bogus for
*precisely* the same reason that the same statement about pointers is
bogus.  The fact that the bit patterns of these objects are the same on
most common architectures is *irrelevant*.  Because the same operations
performed on these objects give different results, and because of this
the bit patterns are best thought of as having a *different*
*interpretation*.  Given that the interpretation is different, it is at
best meaningless and at worst dangerously misleading to say that they
"have the same value".

(If this is what Joe meant by "only different in datatype", then I agree
 with him.  But I disagree that this is a good phrase to use to describe
 this difference.)

(I agree that there are interesting distinctions between the (float) vs
 (int) case and the (int *) vs (int (*)[]) case.  But these distinctions
 are (I believe) not relevant to this point.)

(And lastly, if I thought "a and &a[0] have the same value" meant
 "((void *)a)==((void *)&a[0]) is true", I'd agree.  But I think
 the meaning of "same value" in common use means more than this,
 so I don't agree.)

> jon at amdahl.UUCP (Jonathan Leech)
>> jsdy at hadron.UUCP (Joseph S. D. Yao)

>> Well, yes, in some theoretical architectures I've heard tell of
>> pointers include arbitrary information on e.g. the size of the
>> object.  Any of these actually implemented?
>     You could implement pointers as a triple:
>     (low address, length, offset of current member)
>     for range checking.

The interesting thing here is that the address of an array and the
address of the first element, under the above scheme, would *still* have
exactly the same bitwise value!

This odd result depends on my interpretation of "length", and is derived
from the fact that the length is used for range checking.  The point
about range checking leads to the conclusion that the length is used to
regulate pointer arithmetic, and is thus *not* the length of the item
the pointer denotes, but rather the length of valid addressing
arithmetic from the "low address".  Now, in the case of an array
declared at top level, this range is the length of the array.  But, in
C, the valid addressing range for the first element of an array declared
at top level is *still* *the* *length* *of* *the* *array*!  Thus, in
terms of the above triple, the address of the array

        char a[10];

ought to be (whatever,10,0), and the address of the first element of
this array ought also to be (whatever,10,0).

> mouse at mcgill-vision.UUCP (der Mouse)
> As for what they SHOULD be....a pointer to an array should be just
> that; indirecting off it should result in an array.  There are good
> reasons this isn't done;

I'm a little confused by this.  On most compilers I've used indirecting
a pointer to an array yields an array, so I'm not sure what is meant by
saying that it "isn't done".  Perhaps it means that this isn't common
usage?  I'll agree with that.  But nevertheless, most implementations
get this particular fine point right.

> I have yet to hear an implementation suggested
> that doesn't have worse flaws than the flaw currently under discussion.

I presume this means that most implementations of C have worse bugs than
that of allowing (&array) and returning the address of the first element
instead.  I won't argue with that.  But what I was objecting to was
elevating this common bug to a "standard feature".  I still think it
would be wrong to do so.  If it means anything (and currently it does
*NOT*), (&array) should indicate the address of the whole array, not the
address of its first element.

--
God made integers, all else is the work of man.
                                --- Leopold Kronecker {1823-1891}
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw