Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!bu.edu!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: "array" vs. "&array" ?
Message-ID: <5260@buengc.BU.EDU>
Date: 13 Jan 90 21:46:58 GMT
References: <24521@gryphon.COM> <CHUCKP.90Jan10103228@halley.ncr-fc.FtCollins.NCR.com> <21764@mimsy.umd.edu> <5248@buengc.BU.EDU> <15638@haddock.ima.isc.com>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.lang.c
Organization: Boston Univ. Col. of Eng.
Lines: 56

In article <15638@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <5248@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
>>Usually when you ask for the pointer to an array you get a
>>pointer to the first element of the array.
>
>No, you get a pointer to the entire array (in ANSI C) or an error (in K&R C),
>except in those pre-ANSI compilers that chose, as an extension, to make the
>misinterpretation you describe (usually accompanied by a warning).

"those...that chose" happens to describe all the compilers I can find
(three different pre-ansi, one ansi-I-think (it's gcc with the ansi
switch turned on...)).

>>E.g.:
>>	type_t *aptr, a[MAXINDEX+1];
>>	aptr = &a;
>
>I don't know of any compiler that will accept that line without a diagnostic.

Yup.  Bug-ola.  S'what I get for posting examples instead of code...

To explain why `aptr = &a' instead of `aptr = a', I was
trying to answer the "what do you get when you _ask_ for a
pointer to an array" rather than "how do you make a pointer
to an array" (which is a non sequitur).

>To reiterate the ANSI convention (the only one worth mentioning, since the
>other behavior is really just correcting a "probably typo" for &a[0]):

Nope.  I'd do it `aptr = a' or `aptr = &a[0]', depending on what
I intended to mean by it; if I was going to do `aptr = &a[1]'
a line or two later, I'd use the latter form.

Oh, and the solution, on all the compilers I can get ahold of
(being an empiricist when it's efficacious) will accept and
work as intended if we just replace the offending line with

	aptr = (type_t *) &a;

Whether this is a hack in the compilers or a deliberate misreading
of the std or ambiguously allowed by the std I don't know.

>	type_t (*aptr)[SIZE], a[SIZE];
>	aptr = &a;

Classic C gives a "can't take the address of this object" warning.
ANSI C is ominously quiet.
The program thus produced runs as desired, however, regardless of
the compiler's pedigree.

>Note that "*aptr" and "a" are both array objects, and hence in the rvalue
>context of the compare *each* will be converted to a pointer:
>	if ( &(*aptr)[0] == &a[0] )

				--Blair
				  "Now there's a thought."