davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/26/88)
One of the things which bothers me about the C language is that many
(most) compilers, and lint, complain about taking the address on an
array. Not that it isn't redundant, but there is a good reason for
allowing it as an official part of the language: information hiding.
Information hiding is used to improve modularity, in the sense that no
program which is not manipulating the details of a data type need know
about them. This allows the data type to be redefined in a later version
of a package, or defined in a diferent way on another system, and not
require changes to the source code which uses the data type as a "black
box". Ada programmers are astonished to find that C can do information
hiding at all...
If I want to have a type which is defined in a header file and
manipulated by a series of routines, I can do something like:
typedef int mytype[5]; /* this is the user type */
and write routines to work with these types. However, if I need to take
the address of a type, to pass to a procedure, if I say:
mytype a, b, c;
.
init_mt(&a);
I get a warning about taking the address of an array.
Since the whole object of information hiding is to allow things to be
changed between implementations, I don't want to have the user treat
'mytype' as an array, since the next version might use a struct.
Therefore I must use a construct like:
typedef struct {
int dummy[5];
} mytype;
which allows me to take the address freely without telling the user
anything about the actual type.
NOTE: This applies to addresses of procedures, too, in some cases.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mechris@mimsy.UUCP (Chris Torek) (04/27/88)
In article <10576@steinmetz.ge.com> davidsen@steinmetz.ge.com > One of the things which bothers me about the C language is that many >(most) compilers, and lint, complain about taking the address on an >array. The dpANS requires that &arr be allowed; it produces a pointer to the array, i.e., an object whose type is `pointer to T1', where T1 is the type of arr, `array N of T2'. I have not tried it, but I suspect that PCC can be changed to conform to this rule by removing one test. In cgram.y, somewhere around line 690, there is a rule for `AND term' that begins with ={ if( ISFTN($2->in.type) || ISARY($2->in.type) ){ werror( "& before array or function: ignored" ); $$ = $2; } else if( $2->in.op == UNARY MUL && Changing this to ={ if( ISFTN($2->in.type) ){ werror( "& before function: ignored" ); $$ = $2; } else if( $2->in.op == UNARY MUL && ought to do it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
karl@haddock.ISC.COM (Karl Heuer) (04/27/88)
In article <10576@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: >One of the things which bothers me about the C language is that many (most) >compilers, and lint, complain about taking the address on an array. Fixed in dpANS. >Not that it isn't redundant, Actually it's not redundant -- on compilers that do it right, "a" and "&a[0]" are equivalent and have type "sometype *", but "&a" has type "sometype (*)[]". (If cast to a common compatible type, they will be equal, however.) >but there is a good reason for allowing it...: information hiding. Agreed. It's because of this botch that "jmp_buf" is required to be an array type: it's passed by value to setjmp. Ideally, the argument of setjmp should be of type "jmp_buf *". >NOTE: This applies to addresses of procedures, too, in some cases. It's not clear whether ANSI C implementations will issue warnings for "pf=&f". I hope not; I think that syntax makes more sense than "pf=f", and would use it exclusively if not for the stupid warning on PCC-based compilers. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
guy@gorodish.Sun.COM (Guy Harris) (04/27/88)
> I have not tried it, but I suspect that PCC can be changed to conform > to this rule by removing one test. I have, and you can. However, as I interpret the January 11, 1988 draft, you can also stick "&" in front of a function, so perhaps the warning messge there should be deleted as well.