why cannot assign to function call

[rurpy at yahoo.com]

On Jan 9, 6:47 am, Mark Wooding <m... at distorted.org.uk> wrote:
> ru... at yahoo.com <ru... at yahoo.com> wrote:
> > As a side comment (because it always bugs me when I read this, even
> > though I read it in very authoritative sources), ISTM that C passes
> > everything by value except arrays; they are passed by reference (by
> > passing a pointer to the array by value.)  Admittedly, the close
> > relationship between arrays and pointers makes it easy conflate them.
>
> Arrays are distinctly second-class citizens in C.
>
> Basically, in C, arrays aren't passed at all but there's some syntactic
> sugar so you can squint and con yourself that they're passed by
> reference.
>
> If you try to pass an array, the array name immediately decays to a
> pointer, and the pointer gets passed instead -- by value.  The
> corresponding function parameter must be a pointer to an approrpriate
> kind of thing, though you're allowed to write []s to confuse yourself if
> you like -- T D[] in a function parameter declaration means precisely
> the same as T *D -- to the extent that &D has type T **D and so on.

What is the observable difference between converting an
array to a reference (pointer) to that array and passing
the reference by value, and passing the array by reference?

That is, given a C-like compiler that is the same as
C except that it passes arrays by reference, how would
it differ from an ordinary C compiler?

The choice of terminology (in this case) seems to me to
be a matter of convention rather than any fundamental
observable difference.  I guess the case for pass-by-value
would be a little stronger because one has to have "passing
a pointer by value" anyway (since pointers are first-class
datatypes) and that can be used to describe passing arrays
(as you described).  Adding a second mechanism,
"passing-arrays-by-reference", is perhaps unnecessary,
but not wrong, and may be more easily understandable
to the target audience.