Craig Partridge <craig@loki.ARPA> (01/04/85)
I promised a follow-up to my note about sizeof's behaviour with array parameters that have a stated size. For those who did not see or do not remember the original message, I basically pointed out that C seems a bit inconsistent. Given: ------------------------------------------------------------------- #define ARRAYSIZE 4 int stuff[ARRAYSIZE]; main() { print1(); print2(stuff); print3(stuff); } print1() { printf("sizeof(stuff) = %d\n",sizeof(stuff)); } print2(foo) int foo[ARRAYSIZE]; { printf("sizeof(foo w/ dimension) = %d\n",sizeof(foo)); } print3(foo2) int foo2[]; { printf("sizeof(foo w/o dimension) = %d\n",sizeof(foo2)); } ------------------------------------------------------------------- print1 prints the value equal to 4 * sizeof(int), while print2 and print3 put out the value equal to the sizeof a pointer to integer. I argued that print2 should print the same number as print1, instead of the value produced by print3. I.e. "int foo[4]" should get the same treatment from sizeof(), regardless of whether or not it is a parameter, and the fact that "int foo[]" is equivalent to "int *foo" is simply a special case (this argument has been slightly improved based on hind sight and some perceptive comments received). I also pointed out that K&R is ambiguous on the topic. Section 7.2 states that sizeof(array) gives the total bytes in the array, but it is not clear whether the declaration "int foo[4]" for a parameter is really specifying an array. I got several different responses. Joe Yao (...!seismo!hadron@jsdy) and Jack Jansen (...!vu44!htsa!jack) both expressed the view that while my argument had merit, the compiler probably couldn't do it another way. Joe pointed out that trying to treat parameter foo as a true array was likely to cause the compiler to start trying to access array positions on the stack. Jack suggested that sizeof was implemented too late in the compilation process (he guessed pass 2, does anyone know?) to discover that the declaration was not of the form "int foo[]". David Herron (...!ukma!david) took the view that the 4.2 bsd compilers on the SUN and VAX were broken, and that as he read K&R, sizeof(foo) where foo is declared as "int foo[4]" should always return the size of the entire array, regardless of whether foo is a parameter, local array or global array. Scott McCaughrin (mccaugh@uiuc) took the same view. Herron also expressed the view that both K&R and the tentative C standard were rather ambiguous on this subject. Several other people took the view that K&R implicitly said that arrays passed as parameters are always to be viewed as pointers, and declaring the parameter as an array with a specific size is merely syntactic cruft. Given the range of views, I think I can still safely say that K&R is ambiguous. One might also suggest (w/ David Herron) that the C standard should deal with it. I don't think there is a concensus about what the *right* answer is -- in fact I suspect the decision is wide open. I haven't heard anybody declare there is code that relies on one or another interpretation..... Craig Partridge craig@bbn-loki {decvax,ihnp4,wjh12}!bbncca!craig