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