Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.lang.c
Subject: Re: pointers to arrays
Message-ID: <24496@amdcad.AMD.COM>
Date: 18 Feb 89 00:02:59 GMT
References: <19784@uflorida.cis.ufl.EDU> <13171@steinmetz.ge.com>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 71
Summary:
Expires:
Sender:
Followup-To:

In article <13171@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
| My reading of dbANS is that the address of array has been changed, not
| fixed, and is now broken in another way. Hopefully someone will
| enlighten me as to what part of the standard I'm missing.
| It looks to me as though given:
| 	int flimflam[20];
| that &flimflam has type address of int. I maintain that if flimflam is
| an array [20] of int, then &flimflam is "address of array [20] of int."

Where in the pANS do you read that &flimflam would have type "address of
int"?  All it says in 3.3.3.2 is that

	"The result of the unary & (address of) operator shall be either
	a function designator or an lvalue that designates an object
	that is not a bit-field and is not declared with the registers
	storage-class specifier...  The result of the unary & (address-of)
	operator is a pointer to the object or function designated by
	its operand.  If the operand has type "type," the result has
	type "pointer to type."

In the Rationale section, it says:

	"Some implementations have not allowed the & operator to be
	applied to an array or a function... The Committee has endorsed
	the construct since it is unambiguous, and since data
	abstraction is enhanced by allowing the important & operator to
	apply uniformly to any addressable entity."

I don't think there is any ambiguity here.

| Consider the code fragment:
| 	mytype fuzzbutt, *charlie = &fuzzbutt; /* named after cats */
| 
| if I declare the typedef as:
| 	typedef long mytype;
| everything works. If I declare it as:
| 	typedef struct { int xx[20]; } mytype;
| it still works. But if I say:
| 	typedef int mytype[20];
| 
| The code fragment fails or generates a warning on most existing compilers
| due to taking the address of an array. On an ANSI compliant compiler I
| *believe* that there will be a warning because the address is not of the
| same type as the pointer.

AMD Am29000 High C Compiler V2.1a Fri Feb 17 16:00:19 1989      t.c 
Page 1

(c) Copyright 1987-88, MetaWare Incorporated    Serial 1-AMD999999.
Levels  LINE #
|----+----1----+----2----+----3----+----4----+----5----+----6-
             1 |typedef int mytype[20];
             2 |
             3 |mytype fuzzbutt, *charlie = &fuzzbutt;  /* should be legal */
             4 |
             5 |void
             6 |f()
             7 |{
  1          8 |        int i, *ip, a[20];
  1          9 |
  1         10 |        charlie = &a;           /* legal */
  1         11 |        charlie = &i;           /* illegal */
  1         12 |        charlie = &ip;          /* illegal */
  1         13 |}
E "t.c",L11/C12:        Type "int*" is not assignment compatible withtype "mytype*".
E "t.c",L12/C12:        Type "int**" is not assignment compatible with type "mytype*".
2 user errors   No warnings   

	-- Tim Olson
	Advanced Micro Devices
	(tim@crackle.amd.com)