Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!mcnc!rti-sel!dg_rtp!throopw From: throopw@dg_rtp.UUCP (Wayne Throop) Newsgroups: net.lang.c,net.micro.pc,net.unix Subject: Re: allocating arrays Message-ID: <357@dg_rtp.UUCP> Date: Thu, 22-May-86 16:43:40 EDT Article-I.D.: dg_rtp.357 Posted: Thu May 22 16:43:40 1986 Date-Received: Sat, 24-May-86 05:52:14 EDT References: <200@pyuxv.UUCP> <1181@ncoast.UUCP> <350@dg_rtp.UUCP> <3423@ukma.UUCP> Lines: 181 Xref: linus net.lang.c:8322 net.micro.pc:7953 net.unix:7256 Summary: double (*parray[15])[] is just what I said it was, so there. Theme-Song: da-da-da-DAAA-daaa DA-da-da-DAAA-da DA-da-da-DAAA-da DAA-da-da-DAAA > david@ukma.UUCP (David Herron) >> throopw@dg_rtp.UUCP (Wayne Throop) >>> allbery@ncoast.UUCP (Brandon Allbery) >>> | ??? > [My mailer doesn't know anything about dg_rtp.UUCP, could you please > let uucpmap@cbosgd know of your existance????] [It has been done, long ago. We are (finally!) on the latest maps. Also, my .signature shows a path to dg_rtp from mcnc, and mcnc is quite well known (being part of the backbone, I beleive).] >>> | Consider an array of 15 pointers to arrays of doubles: >>> | double (*parray[15])[]; >>> double (*parray[15])[]; means: >>> an indefinitely-sized array of (or a pointer to) >>> an array of 15 >>> (double *) >>Wrong. It means just what the original poster said it meant. It is an >>array of 15 pointers to arrays of double. > I respectively submit that you're full of it and that Brandon is correct. I exasperatedly submit that I'm quite empty of it, and that Brandon is as wrong as wrong can be. Also, after saying I'm wrong, your examples go on to support my position strongly, so you've succeeded in puzzling me no end, as well as prolonging this discussion beyond it's natrual span. But meanwhile, long ago, in an address space far, far away.... POINTER WARS The Evil Empire has attempted to perpetuate the fallacy that pointers are the same thing as arrays. The brave, outnumbered, noble, correct, long- suffering rebel alliance has always maintained that the Force keeps pointers and arrays distinct. Our hero (moi) has lived a peaceful existance on the out-of-the-way node dg_rtp for years, until finally an empire star destroyer (which insists that stars ("*") in declarations can be replaced by brackets( "[]")) finds dg_rtp via the news network, and opens fire.... Let's listen in, as the battle begins... > [Shhhh-Pfoooo... Shhhh-Pfoooo...] [You can't fool me, Darth Vader! I know that's you behind the life-mask!] > Using []'s in a declaration is SIMILAR to declaring a pointer, 'cept > that the pointer is an internal constant in the compiler, and if you > fill in a value inside the []'s it allocates some space. A stumbling > point is when a [] declaration is an arg to a function, THAT gets > translated to a * declaration... Yeah, right, [] is just like a pointer, except that it isn't, really. Give me a break. A [] declaration always declares an array, and arrays and pointers are *NOT* (I'll repeat for those who have trouble understanding this concept: *NOT*) the same thing. The fact that array formal arguments must "actually" be pointers is no more significant than the fact that character formal arguments must "actually" be integers. And while declaring *anything* is to some degree similar to declaring anything else, pointers and arrays are not really very similar. > Some examples: > > char a[] = "this is a character string\n"; > char b[]; > > (oh, they're both external decl's) Tell me tho, what USE is a > the declaration of b[]???? Translating the decl to *b isn't > doing what I SAY, and (on Unix anyway) what I SAY is what I MEAN. What's the big deal? This says that "a" is an array 28 characters long (unless I've counted wrong... which is the reason for this shorthand in the first place), and storage for "a" is allocated in this file, and initialized to the given string. In addition, you are saying that "b" is an array of unknown size, and storage for it is *not* allocated in this file (that's why it can be of unknown size... the storage will be allocated somewhere else). (What use is "b"? My good sir, what use is a baby?) Given all this, is it hardly surprising that > Anyway, compiling I get: > Undefined: _b since you implicitly promised to allocate space for "b" somewhere else, and then didn't do it. So where's the strangeness? How does all this flapdoodle support your contention that "double (*parray[15])[]" isn't an array of pointers to arrays of double? [ Let me be clear about what "shorthand" I'm talking about above. In C, the declaration char a[] = "ab"; is shorthand for char a[3] = {'a', 'b', '\0'}; (though there is some debate as to whether that "'\0'" should be "0" instead, or exactly what '\0' means (does it mean zero or ascii null?)) This is *NOT* the same as the declaration char *a = "ab"; which isn't shorthand for anything, and which behaves quite differently. The array declaraction allocates storage of size 3, and initializes those three characters to the values given. The pointer declaration allocates storage for one pointer (on our machine, of size 4), and initializes it to point at the first character of a constant array of size 3. As I say, quite different. ] > [another example, simplified: > f(){ > char b[]; > printf( ... b ...); > } ] > Looking at the assembler output, b[] is a pointer > to the top of the stack but there's no space allocated to it. Actually, the declaration of b is illegal, and our compiler complains bitterly about it. I assume your compiler treated it as a zero-sized array. I doubt that it treated it as a pointer, as you suggest. (Interestingly, lint doesn't complain about it. It certainly ought to.) >> [verbose typechecker output, deleted] > er... where did you get that program? I agree with it somewhat EXCEPT > it's not making a distinction about CONSTANT pointers a la arrays. It's > an interesting program nonetheless... Well, the program is a typechecker that was locally written to check the rules as laid out in Harbison and Steele, sort of the new testament to K&R's old. Sadly, I'm not currently at liberty to release it. It is making all the distinctions it should. It was created in essence by going through H&S (as well as K&R), and translating the type rules found there into checks performed against the parse tree of the input C program. Each error message is in fact related back to where H&S justifies calling the construct an error. I trust it a fair amount more than I do lint (though, to my utter dismay, it didn't complain about "f(){char b[];}" either... if anybody can justify why that should be legal (as I say, our compiler complains bitterly), I'd appreciate a message explaining why). > I agree with you that the compilers need to produce better error messages. Good. I hope you now also agree that compilers should keep the differences between pointers and arrays straight. Keep away from the Dark side of the Force, and you can't go wrong. I stress again, the declaration int (*a)[]; is *NOT* (i say) *NOT* (i say again) *NOT* the same as the declaration int **a; and any entity that thinks they *are* the same thing is, quite simply, mistaken. Trust me folks... I'm right about this. If you think these two are the same, you simply haven't thought about it enough. -- "Luke... use the Force!" -- "He's turned his targeting computer off!" -- Stay tuned for the next exciting episode, The Umpire Strikes Out Coming soon to a netnode near you! -- Wayne Throop !mcnc!rti-sel!dg_rtp!throopw