Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: Address of array
Message-ID: <422@umcp-cs.UUCP>
Date: Fri, 21-Mar-86 07:04:26 EST
Article-I.D.: umcp-cs.422
Posted: Fri Mar 21 07:04:26 1986
Date-Received: Sat, 22-Mar-86 22:40:52 EST
References: <750@abic.UUCP> <211@dg_rtp.UUCP> <685@steinmetz.UUCP> <58@paisley.ac.uk>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 53

In article <58@paisley.ac.uk> rh@cs.paisley.ac.uk (Robert Hamilton)
takes exception to something in article <211@dg_rtp.UUCP> by
throopw@dg_rtp.UUCP (Wayne Throop), who writes:

>>I believe that to support reasonable portable code C *must* allow
>>the address operator on an array, even if it is not required.

Robert says:

>Taking the address of an array just doesnt make sense in C.

I think you missed the point.  Suppose you write the following:

	#include "../projlib/types.h"

	x_type	variable;

	f()
	{
		g(&variable);
		...
	}

	g(p)
		x_type *p;
	{
		x_type newvalue;

		...
		*p = newvalue;
		...
	}

This looks perfectly reasonable, and works quite well if `x_type'
is a name for a simple type, a structure, or a union.  It does not
work---indeed, it does not even compile---if `x_type' is a name
for an array.  The problem is that you are not `allowed' to know
just what `x_type' really is.

As it turns out, it is not often useful to write something like
the above if `x_type' is a name for an array, and this problem does
not seem to come up in practice---or at least I have not seen it.
And if all else fails one can always wrap the array in a structure:

	typedef struct {
		int	x_val[10];
	} x_type;

This does seem a bit of a kludge, though.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu