extern declaration inconsistency (acticle 185).

[John Hallam]

Article 185 refers to the problems that arise when a name is declared

char ch[...];		/* in the first file */

extern char *ch;	/* in another file */

It appears that the name is not correctly linked.

------------------

The answer to the question raised is that it is not a compiler bug, but it
might be called a feature depending on your definition of those. It is a
part of the language definition!

For those who knwow about l-values and r-values the explanation is this:

In C, array names (and function names) denote an r-value CONSTANT which is
determined at link editing time; most other variable names denote l-values
and implicit contents coercion is done when necessary.  Thus in the above,
the name 'ch' is first defined as an array (I use first in the sense that this
declaration actually allocates space for the array) and denotes the address
of the storage in which the characters will go.  The second declaration informs
the compiler that 'ch' is an l-value, i.e. the name now denotes the address
of storage in which a pointer value can be put.  Thus accessing 'ch' under the
second declaration actually gives the value of the first word of the array!

The problem encountered here is more faulty explanation in K&R of identifier
semantics than anything else.  In an r-value context (when used in expressions)
the two declarations give the same TYPE, but the pointer declaration implies a
contents coercion (which in this case fetches the first word of the array)
and the array declaration implies no contents coercion (because the name 
already denotes an r-value). Conversely, you can assign to the pointer declared
name 'ch', because it is an l-value (this is just what l-value means -- can
stand on the left of assignments), but if you try to assign to the array
declared name 'ch' you'll get a message 'Lvalue required' or something like it
from the compiler.

I hope this makes things a little clearer.

		John Hallam.
			(edai!john).