Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mtx5a.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!whuxl!whuxlm!akgua!akguc!mtunh!mtuni!mtune!mtunf!mtx5c!mtx5d!mtx5a!esg
From: esg@mtx5a.UUCP (ed gokhman)
Newsgroups: net.lang.c
Subject: re: pointer to array
Message-ID: <1234@mtx5a.UUCP>
Date: Fri, 7-Mar-86 10:57:22 EST
Article-I.D.: mtx5a.1234
Posted: Fri Mar  7 10:57:22 1986
Date-Received: Mon, 10-Mar-86 00:18:04 EST
Distribution: net
Organization: AT&T Information Systems, Middletown, NJ 07748-4801.
Lines: 63

>    z = &x is illegal although the types would match

No types do not match here:
	(int (*)[5]) != (int **)

>    z = &y[2] is illegal, for no good reason (my opinion)

There is a good reason:
	(int (*)[5]) != (int **) 

There are also quite a few strange sizeofs like:
>    sizeof &*(*z.r) == 4 if pointers are 4 bytes
what meant, I think, was 
	sizeof &*(*z).r


At any rate, a valid point was made. I have another example.
Although, the logic of language interpretation is understandable,
the result is not elegant:

typedef int	foo[5];
foo	a;

main()
{
	funct( a );
}
int
funct ( b )
foo b;
{
foo c;
	printf("%d\n", sizeof b);	/* result is 4 if ptr is 4 */
	printf("%d\n", sizeof c);	/* result is 20 */
}

I think, a compiler should appreciate the fact that b
was not declared as int * but as int [5] and give a
correct size of declared object. Otherwise, it
simply should not allow a declaration of a formal parameter
as an array.

Similar situation may be observed in the new C compilers,
where formal parameter may be declared as a function but
will be interpreted as a pointer to a function.

Another example, where C could be more elegant is the
following:

file1.c:
	int	a[5];
	...

file2.c:
	extern	int	*a;
	...

This one compiles fine, but just watch out at run-time !

I think, that "intimate relationships between arrays and pointers"
should be cool off a little bit for the sake of stronger typing.

				Ed Gokhman