ref. to array != ptr

[Blair P. Houghton]

There are parts of the standard defining when an array
identifier _in_an_lvalue_context_ is converted to a pointer
to its first element and when it is not[1]; there are parts
that say that types are compatible essentially when they
are identical and not otherwise[2]; therefore,

	extern char *foo;

in one translation unit (e.g. loop.c) can not be
dereferenced to yield the first member of the object
defined by

	char foo[SIZE];

or

	char foo[] = "string";

in another translation unit (e.g., main.c).

It appears that one can, from the facts given[3], only
_infer_ this result.

My question (and I've just spent a butt-deadening hour
sitting in my chair hunched over the standard trying to
answer it for myself[4]) is:  is there anything more
explicit stating that the declaration of an externally-
defined pointer to Type can not specify an array of Type
with the same identifier defined externally?

One other thing stands to reason:  every time you use a
pointer to access an array, you have to define the pointer
and _assign_ the array's address to that pointer; it makes
no sense to redeclare array foo[] as a pointer in the same
translation unit in which it is defined, so that should not
lead you to do so in another translation unit.

[1] ANSI X3.159-1989, sec. 3.2.2.1, p. 37, ll. 15-19

[2] This is not strictly true (ibid. s. 3.1.2.6, p. 26, footnote 21)
but holds for pointer types (ibid., sec. 3.5.4.1, p. 67, ll. 24-25)
and array types (ibid., sec. 3.5.4.2, p. 68, ll. 11-12).

[3] That `foo' as used in (1) and (2) are not in an lvalue
context, and that a pointer is not identically an array

[4] Next time I'll open it.  :-)

				--Blair
				  "My other question is, how in the
				   hell did I never before make this
				   apparently easy mistake?"