Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!uniq!rjnoe From: rjnoe@uniq.UUCP Newsgroups: comp.lang.c Subject: Re: static char (*b)[6]; Message-ID: <306@uniq.UUCP> Date: Wed, 17-Jun-87 13:51:46 EDT Article-I.D.: uniq.306 Posted: Wed Jun 17 13:51:46 1987 Date-Received: Fri, 19-Jun-87 05:08:13 EDT References: <304@uniq.UUCP> <6658@auspyr.UUCP> Followup-To: poster Organization: Uniq Digital Technologies, Batavia, IL Lines: 96 In article <6658@auspyr.UUCP>, mick@auspyr.UUCP (Mick Andrew) writes: > >in article <304@uniq.UUCP>, rjnoe@uniq.UUCP (Roger J. Noe) says: > > . . . The array cannot be passed as a function parameter. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Think again, squire. Until some real standard becomes established and generally accepted the next best thing we have to a definition of the C language is found in Kernighan and Ritchie, 1978. From section 1.8 "Arguments - Call by Value" (bottom of page 24): "When the name of an array is used as an argument, the value passed to the function is actually the location or address of the beginning of the array. (There is *no* copying of array elements.)" [emphasis in the original] Similarly in section 5.3 "Pointers and Arrays" (pp. 94-95). Also in section 10.1 "External function definitions" (p. 205): "Also, since a reference to an array in any context (in particular as an actual parameter) is taken to mean a pointer to the first element of the array, declarations of formal parameters declared `array of ...' are adjusted to read `pointer to ...'." Even when enums were added in 1978 and restrictions on structs were relaxed to permit assignment, return by function and passing as arguments, there was no change in C to pass arrays as function arguments. Perhaps some C pro- grammers are accustomed to compilers which do allow this but they are very nonstandard C compilers. I should think that every novice C programmer would know you cannot pass an array as a function argument. All you can do is pass a pointer to one of its elements. So when you've got "char (*b)[6];" and you try to pass "*b" to a function, the compiler knows it cannot pass an actual "char [6]" but has to take the address of it and pass the pointer. In effect what happens is to pass "&(*b)" or just "b". This is why the value of "b" is passed whether one writes "b" or "*b" as the actual parameter. It's much like having "char x[6];" and passing "x" as an argument. > > I think the referenced publication should look for a programmer who knows > > his/her/its C better than this one. Or maybe change their name to > > "Unprofessional". > Now then, Roger, did you read the article, or are you taking the clippings > in the original posting out of context? It must be one of Murphy's laws that whenever you omit a ":-)" from an article, somebody will get very offended and flame back at you. I did not read the original article in The DEC Professional until after I posted mine. What prompted me to add a bit of sarcasm was the exceedingly opaque and almost completely false quote from Rahul Dhesi's posting: > In article <761@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > . . . . The columnist continues, "...This means > that *b is a constant and while (b) can be modified, *b never will > change its original value. Thus, setting b = d does not mean that > *b == *d. Also, while *b is treated as a constant (unchangeable), the > value of b can vary." What's wrong with this is that these words are not those of the columnist, Rex Jaeschke, but of the "college level" teacher of C who wrote to Jaeschke in the first place. My snide remark, based on the posting that started all this in comp.lang.c, was misplaced and undeserved as far as Jaeschke and The DEC Professional are concerned. I retract the statement and apologize to anyone who was offended by it. HOWEVER, had a publication of this caliber employed a writer for a column of the same nature as "Let's C Now", holding himself forth to be a professional C programmer, and had he made the statement above, I would not retract the comment I made in response. If such a situation were to occur, the remark would be deserved. I'm glad Jaeschke doesn't identify the writer of the letter; I truly do not want to know where this person teaches "college level" C language. > When I saw Rahul's posting, I knew we were in for another round of > "leap before you look postings" . . . It's funny, Mick, but yours was the first such posting I saw. It's also the first one that failed to make any technical contribution to the issue. > Recommendations: > 1) (to all) Read the article if you can get a copy. I concur. It's not always easy to get a copy, but Jaeschke's articles on C have been and continue to be worthwhile. > 2) (to Roger) Consider a name change. > ---- > Mick In fact I considered a name change. I thought either Mick or even Andrew might be interesting choices, but I was afraid people would think I was an idiot. :-) I had the courtesy not to mention the name of the publication when being sarcastic. Courteous netters don't make disparaging remarks *at* other netters, especially not in a "technical" newsgroup. And they do apologize when they make mistakes. Consider it, Mick Andrew. -- long tloc = 507314353L; Roger Noe ihnp4!uniq!rjnoe Uniq Digital Technologies rjnoe@uniq.UUCP 28 South Water Street +1 312 879 1566 Batavia, Illinois 60510 41:50:56 N. 88:18:35 W.