Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!munnari.oz.au!metro!wolfen!pejn
From: pejn@wolfen.cc.uow.oz (Paul Nulsen)
Newsgroups: comp.lang.c
Subject: Re: extern char *foo vs. extern char foo[]
Summary: arrays are treated differently
Keywords: by reference, by value, arrays
Message-ID: <6273@wolfen.cc.uow.oz>
Date: 6 Jun 90 00:59:16 GMT
References: <1990May30.001219.23564@uunet!unhd> <6263@wolfen.cc.uow.oz> <16788@haddock.ima.isc.com>
Reply-To: pejn@wolfen.cc.uow.edu.au (Paul Nulsen)
Organization: Uni. of Wollongong, NSW, Australia.
Lines: 24

In article <16788@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>
>Actually, function arguments in C are *always* passed by value ...
>
>In the case of an array, strictly speaking, a true call by reference in this
>sense would be `void f(int (*pa)[N]); ... f(&a);', where the user explicitly
>passes the address of the array (and the caller expects it)...

My argument is not that there is internal inconsistency in the treatment of
arrays by C. The inconsistency is between the treatment of arrays and other
types. If the syntax of C was entirely consistent an `a' in a
function argument would push the entire array onto the stack. For example,
	int a[10];
	printf ("%d\n", sizeof(a));
produces 10 * sizeof(int). For any other type (including struct's) the thing
pushed onto the stack is the value of the entire entity, using a space equal
to sizeof (entity). This is not meant to be a criticism of C, just an
observation about the source of confusion.

You have produced yet another illustration of the confusion caused by the
handling of arrays. C compilers will ignore the & in f(&a). This is because,
within the scope of the array definition, there is no data location where
the address of a is kept. If the compiler was pedantic (and did not concede
some inconsistency) it should reject this as a syntax error.