Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!decvax!mcnc!rti-sel!dg_rtp!throopw From: throopw@dg_rtp.UUCP (Wayne Throop) Newsgroups: net.lang.c Subject: Re: Pointers and Arrays Message-ID: <509@dg_rtp.UUCP> Date: Mon, 11-Aug-86 13:35:37 EDT Article-I.D.: dg_rtp.509 Posted: Mon Aug 11 13:35:37 1986 Date-Received: Tue, 12-Aug-86 23:24:31 EDT References: <1242@ncoast.UUCP> <418@dg_rtp.UUCP> <1267@ncoast.UUCP> Lines: 108 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@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@amdahl.UUCP (Jonathan Leech) >> jsdy@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@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 !mcnc!rti-sel!dg_rtp!throopw