Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!ut-sally!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.lang.c,net.micro.pc,net.unix Subject: Re: And now this pointer bullshit is confusing EVERYONE! Message-ID: <4676@sun.uucp> Date: Tue, 1-Jul-86 17:08:01 EDT Article-I.D.: sun.4676 Posted: Tue Jul 1 17:08:01 1986 Date-Received: Thu, 3-Jul-86 05:57:07 EDT References: <1242@ncoast.UUCP> <418@dg_rtp.UUCP> <1267@ncoast.UUCP> <4609@sun.uucp> <1274@ncoast.UUCP> Organization: Sun Microsystems, Inc. Lines: 108 Xref: watmath net.lang.c:9697 net.micro.pc:8953 net.unix:8489 > > This was intended to allocate an array and assign it to a variable of type > > ``pointer to array of (struct sfld). I suspect the type is wrong but I'm > > not sure how to decalre such a beastie; I suspect that it *does* *not* > > *exist* *at* *all* in C, now that I've played with it. > Wrongo. "struct sfld (*cursf)[]" *is* a declaration of a pointer to an > array of "struct sfld". > Which was my point... Your point, as stated in the portion of your article that I quote, is that you suspected that there is no type "pointer to array". There is such a type. > > This could easily have been done correctly: > > > > int array[3]; -- should declare a pointer followed by 3 integers, > > with the pointer initialized to the 3 integers > > int array[]; -- should decalre a pointer. > > No, NO, *NO*, ***N*O****, ... > If you had read more carefully and applied what you know of C, it would have > been YES!!! Think about it for awhile. I was trying to make a language > which is C-compatible but handles arrays correctly. Don't like it? Then > why in the name of the Witness are you bitching about pointers-vs.-arrays??? Why in the name of "the Witness" (whatever *that* is) does providing these useless pointers make your proposed language handle array "correctly"? C handles arrays well enough for me - an array is an array, and there is no pointer involved. What languages other than BCPL and maybe B declare a pointer cell like this? PASCAL doesn't, Modula-2 doesn't, FORTRAN doesn't, etc., etc.. Do they handle arrays incorrectly? No, I *don't* like it. Those pointers are useless, and certainly don't make handing of arrays "correct". > > > C should treat ``int array[]'' as a different type from ``int *ptr'', > > It does. That's what people have been trying to tell you! > > Modulo some other type not being assignable (if it's initialized or given as > array[n], it's a constant value), I am again correct. Only if it can't be > made a compile-time constant is it a pointer. Clear? No, it is not clear, because you are NOT correct, despite any feelings you have to the contrary. The *O*N*L*Y* place where declarations of int array[]; and int *ptr; declare objects of the same type is if the "int array[]" is declaring a formal parameter. The only other place where "int array[]" can be used is as an external declaration, in which case it declares an *array* (NOT a pointer) of unspecified size; the size is set by the external DEFINITION of "array", in this or some other module. > C doesn't *have* arrays. ``int a[3]'' decalres three ints and a constant > pointer to the first. If it declared it as an ARRAY none of this would be a > problem. The above statement is completely false, unless you have a VERY strange defnition of an array. What is an array "int a[3]" other than three ints? In YOUR proposed language, "int a[3]" may declare a pointer. In C, there is no pointer declared. The expression "a" is an ARRAY-valued expression (if you don't believe me, try reading the ANSI C draft), which is coerced in MOST circumstances (NOT all - in the expression "sizeof a", it is not so coerced, and "sizeof a" has the value 3*sizeof(int)). > I maintain that C doesn't support arrays, it merely fakes something with > semantics similar in SOME contexts. The only difference between C arrays and arrays in some other languages is that array-valued expressions are coerced, in most cases, to a pointer-valued expression. That seems to cause some people problems. Other people have no problem with it at all. > int a[3]; --> (a[0])(a[1])(a[2]) > int *b = malloc(3*sizeof (int)) --> (b[0])(b[1])(b[2]) > THESE are different??? -----------^^^^^^^^^^^^^^ No, they're not different - BUT the latter is not the layout of "b", but what "b" *points to*. "a" is an array-valued expression, which is is in most circumstances coerced to a pointer-valued *expression* - said expression does not *have* a storage location. "b" is a pointer-valued expression which *does* have a storage location. "a", in those circumstances when it is NOT coerced to a pointer-valued expression, has a storage layout which is NOT the same as the storage layout of "b". End of discussion. > +--------------------^^^^^^^^^^^ Golly gee, you might even understand! I've understood C arrays and pointers from the beginning. Your condescending tone is offensive and inappropriate, since you don't seem to understand them. > Which is what I am saying is a mistake. Glad you finally noticed. > Further flames to /dev/null. C is just plain a botch. I've considered C arrays to have a problem for a while, because some people have trouble understanding them. If you want to consider C to be "just plain a botch" because of this, fine. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)