Address of array

[Sam Kendall]

In article <227 at valid.UUCP>, sbs at valid.UUCP writes:
> When I last left it, the [ANSI] 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)));

The point is uniformity of reference, or, more specifically, freeing the
programmer from (some) worrying about what type underlies a typedef.  In
this case, if you want to get a pointer to a variable, you shouldn't
have to worry about whether the variable is an array or not, you should
just be able to say, for variable `v', `&v'.  Total uniformity of
reference is impossible for arrays, of course, but allowing
address-of-array brings the language a bit closer.

> (This objection is rather neatly removed by
> 
> 	typedef struct {
> 		int once_upon_a[2];
> 	} time_t;
> 
> but never mind.
> )

This won't work for jmp_buf, which must be an array in order to allow
calls with the documented syntax, for jmp_buf jb, `setjmp(jb)'.

> 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.

No, they'll say, "Use lint, and you will find that only the first strcpy
is correct."  Lint complains about the last two.  Your gotcha is only a
gotcha if you don't use lint, in which case there are millions of other
gotchas.

----
Sam Kendall			{ ihnp4 | seismo!cmcl2 }!delftcc!sam
Delft Consulting Corp.		ARPA: delftcc!sam at NYU.ARPA