Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtech.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!amdahl!rtech!jas
From: jas@rtech.UUCP (Jim Shankland)
Newsgroups: net.lang.c
Subject: Re: arrays/pointers in C
Message-ID: <459@rtech.UUCP>
Date: Sun, 2-Jun-85 01:40:54 EDT
Article-I.D.: rtech.459
Posted: Sun Jun  2 01:40:54 1985
Date-Received: Tue, 4-Jun-85 00:45:06 EDT
References: <226@ihdev.UUCP> <6000001@mirror.UUCP>
Organization: Relational Technology, Alameda CA
Lines: 25

> array==pointer ... is only true when "array" is being passed
> or received as a parameter.  In this case, the C [sic] automatically
> changes all array names (e.g., foo(arr)) into addresses of the
> first element (e.g., foo(&arr[0])).

At the risk of picking nits, the above statement is not quite correct:

An identifier of an array object is ALWAYS read as a pointer to the
first element of the array, except in the declaration itself.  The subscript
operator ("[]") is a variant of the dereferencing operator '*' that supports
the notion of an offset.  "a[b]" is completely, syntactically, semantically,
and rigorously IDENTICAL to "*(a+b)" (except, again, in an actual declaration).
Of course, for the above to make sense, one of the operands must be a
pointer to something, and the other an integral type; but it doesn't matter
which is which.  It follows that "a[b]" is equivalent to "b[a]" -- a
notion that most people will not accept without a little head-scratching.

So "&arr[0]" is equivalent to "arr", since "&arr[0]" is identical to
"&*(arr+0)".  Far from internally converting "foo(arr)" into "foo(&arr[0]"),
the prudent compiler would read the latter construct, fold out the addition
with 0 and the "&*", and be left with the former construct.

Jim Shankland
..!ucbvax!mtxinu!rtech!jas
..!ihnp4!pegasus!rtech!jas