Array pointers (was: Re: Possible Bug in BSD)

[guy at gorodish.UUCP]

(This has drifted away from UNIX issues and towards C issues.)

>>main (argc, argv)
>>int argc; 
> vvvvvvvvvvvv
>>char **argv;
> ^^^^^^^^^^^^
>>{
>> ...
>>	if((f1 = fopen(argv[1], "r")) == NULL )

>You really shouldn't have declared char **argv if you want to treat
>argv as an array.

But "argv" *I*S*N'*T* an array.  It's a pointer to the first element
of an array.  To be precise, it's a pointer to the first element of
an array of pointers to "char", which is why it has type "char **".

>Instead, change that declaration to *argv[]

Since "argv" is a parameter, the compiler will interpret a parameter
declaration like "char *argv[]" as "char **argv".  K&R, Page 205:

	Also, since a reference to an array in any context (in
	particular as an actual parameter) is taken to mean a pointer
	to the first element of the array, declarations of formal
	parameters declared ``array of ...'' are adjusted to read
	``pointer to ...''.

October 1, 1986 ANSI C draft, page 71:

	Because array expressions and function designators as
	arguments are always converted to pointers before the call, a
	declaration of a formal parameter as ``array of *type*''
	shall always be adjusted to ``pointer to *type''...

>I suspect that C doesn't treat arrays of pointers exactly as it treats
>pointers to pointers, but I'm not really that sharp on the subject.

That's true, except that you can't declare formal parameters of type
array (see above), so in this case, unfortunately, it *does* sort-of
treat them the same.  (I wish it hadn't, given all the confusion it
seems to cause.)  However, in most situations array-valued
expressions are converted to pointer-valued expressions that point to
the first element of the array in question (another source of
confusion), so they are often treated very similarly.

>Some C compilers will give you "type mismatch" errors when you define a
>pointer value and then reference it as an array.

No program that gives a "type mismatch" on something like

	...
	char **argv;
	{
		...

		if ((fp = fopen(argv[1])) == NULL) {
			...

is a C compiler.  It may be a compiler for a language resembling C,
but it's not a compiler for C.  The C subscripting operator does
*not* apply to arrays at all; it *only* applies to pointers.  "a[i]"
is defined to mean "*(a + i)".  K&R, page 210:

	...By definition, the subscript operator [] is interpreted in
	such a way that E1[E2] is identical to *((E1)+(E2)).

The October 1, 1986 ANSI C draft says the same thing (in almost the
exact same language) on page 32.

The reason this works on arrays is that array-valued expressions are,
except in a few circumstances, converted to pointer-valued
expressions that point to the first element of that array-valued
expression.  As such, if you declare "int foo[32]", the
sub-expression "foo" of the expression "foo[8]" is converted to a
pointer to the first element of "foo".  This means that converting
"foo[8]" to "*(foo + 8)" is valid.  8 is added to the pointer-valued
expression in question, yielding a pointer-valued expression that
points to an "int" 8 elements further into the array than the one
pointed to by the pointer-valued expression that "foo" is converted
to.  Since the latter expression points to the first element, the
former expression points to the ninth element (remember, C arrays are
0-origin arrays, so the Nth element is "array[N-1]").  Then "*(foo + 8)"
refers to the element of the array pointed to by that pointer-valued
expression, namely the ninth element.

Please, people, if you're going to make a claim that some proposition
X about the C language or some piece of C code is true, be certain
that this claim can be justified by some bit of K&R, H&S, the ANSI
draft standard, or something like that before posting.