Follow-up to sizeof question

[Craig Partridge]

	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 at 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 at 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 at bbn-loki
{decvax,ihnp4,wjh12}!bbncca!craig