pointers to arrays

Tim Olson tim at crackle.amd.com
Sat Feb 18 10:02:59 AEST 1989


In article <13171 at steinmetz.ge.com> davidsen at 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 at crackle.amd.com)



More information about the Comp.lang.c mailing list