Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site valid.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!pesnta!valid!sbs
From: sbs@valid.UUCP (Steven Brian McKechnie Sargent)
Newsgroups: net.lang.c
Subject: Re: Address of array
Message-ID: <227@valid.UUCP>
Date: Thu, 17-Apr-86 00:11:22 EST
Article-I.D.: valid.227
Posted: Thu Apr 17 00:11:22 1986
Date-Received: Fri, 18-Apr-86 20:34:18 EST
References: <750@abic.UUCP> <211@dg_rtp.UUCP> <685@steinmetz.UUCP> <58@paisley.ac.uk> <260@peregrine.UUCP> <88@paisley.ac.uk>
Organization: Valid Logic, San Jose, CA
Lines: 42

> In article <260@peregrine.UUCP> mike@peregrine.UUCP (Mike Wexler) writes:
> >In article <58@paisley.ac.uk> rh@cs.paisley.ac.uk (Robert Hamilton) writes:
> >>
> >>	(Much flamage about "right" way to interpret cettes choses)
> >	(Much flamage about "right" way to interpret cettes choses)
>	(Much flamage about "right" way to interpret cettes choses)

The ANSI debate on the C standard, which has devolved into a wide variety
of entertaining circuses, recently had a sidelight into the &array issue.
When I last left it, the committee was leaning toward allowing &array so that
programmers could portably declare and use thusly:

	typedef int time_t[2];
	...
	time_t t;
	printf("%s", (time(&t), ctime(&t)));

(This objection is rather neatly removed by

	typedef struct {
		int once_upon_a[2];
	} time_t;

but never mind.
)

I lean in the opposite direction (I believe that &array is an undesirable
construct) because of the following gotcha:

	char a[200][40];
	char *b[200];
	...
	strcpy(b[i], a[i]);	/* works */
	strcpy(b[i], &a[i]);	/* works */
	strcpy(&b[i], &a[i]);	/* don't work */

Of course, adherents to strong typing will say, "Thou fool.  Declare
strcpy(char *, char *) in thy headers," and they're perfectly entitled
to their opinions.


S.