kpmartin@watmath.UUCP (Kevin Martin) (01/18/85)
All the following assumes the existance of the formal parameter
declarations as described in the proposed draft standard.
The basic observation is that the formal parameter information is actually
part of the function's type, rather than a separate characteristic
of the function itself. That is, if I say
extern int fun( char *, int );
'fun' is not a function returning int, and a function accepting
arguments of type char * and int, but is actually a function of
type "function accepting a char * and an int returning int".
Similarly, I can type things like
typedef int (*funny)( char *, int );
which is a pointer to function accepting a char * and an int returning
an int. An object of type 'funny' could be used to point to 'fun'.
Question:
Given the above, and:
extern int herbie( int, double );
should I be allowed to assign a pointer to 'herbie' to an object of
type 'funny'? In other words, should pointer-to-function types be
considered assignment-compatible ONLY if both the return type and
the formal parameter declarations match?
Related questions:
What about functions for which no formal parameter declaration has
been supplied?
How about making such types assignment-compatible as long as
the return type is the same, and all the arguments match in a somewhat
looser sense, i.e. int matches unsigned, char * matches unsigned char *,
as well as other such type pairs which are "usually assumed" to be identical?
The current situation is that function pointer types are assignment-
compatible as long as the return types are the same.
If the strict interpretation is taken, the number of distinct
pointers to functions will become quite large even for a small set
of return types, and it is back to the old question:
What do we use for a generic function pointer?
Kevin Martin, UofW Software Development Grouphenry@utzoo.UUCP (Henry Spencer) (01/19/85)
> ... In other words, should pointer-to-function types be > considered assignment-compatible ONLY if both the return type and > the formal parameter declarations match? Probably. This would seem to be a hole in the fussy type-checking of the current ANSI draft. > What do we use for a generic function pointer? Damned if I know... I think the situation would be the same as the one for data pointers before "void *": you have to use casts everywhere. It's not obvious to me that we need a function-pointer equivalent of "void *", since I don't remember any function-pointer analog of malloc. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> (01/20/85)
Why do you need a generic function pointer? In any use of a function pointer, e.g. (*funcp)( arg1, arg2 ); the arguments must be of correct type for ANY function that can be assigned to the pointer. Seems to me this is just waht one wants. It sure would've made finding that bug in libI77.a that I posted yesterday much simpler, since "lint" would be able to do strict type checking on ALL type attributes of function pointers.