Function-types: compatability, and typedefs

[Chris Torek]

In article <KERS.89Aug31164048 at cdollin.hpl.hp.com> kers at hpld.hpl.hp.com
(Kers) writes:
>if I cast (say) (int (*)( void *, void *)) strcmp, and pass it to (say) qsort
>(as the compar parameter), can I expect it to work, and does such usage
>conform to the pANS? (I suspect the answers to be Yes (on many 
>implementations) and No, respectively).

Actually, the answers FOR THIS PARTICULAR CASE are `yes' and `yes'.

Given a pointer whose type is <pointer to function (args) returning t>,
you can always (by the proposed standard, at least) cast it to some
other function pointer type (<ptr to fn (args') returning t'>) and then
back, and the result (after casting back) will act the same as the
original.  Normally, however, you have to use that `cast-back' to force
it to work.  In this particular case, however, the two types are

	int (*)(void *, void *)		[qsort compare function]
and	int (*)(char *, char *)		[strcmp]

and `void *' and `char *' are required to be `the same' in
representation, since historically `char *' has been used where the
pANS uses `void *'.  (In fact, in Classic C, qsort's fourth argument
has the second type above, not the first.)  In order not to break such
code, the pANS has a constraint that is supposed to make those two
function-pointer types interchangeable.

Whether this might be `deprecated' (and hence vanish in C-00 in 2001,
or whatever), I am not sure.  Certainly it would be prettier to cast
back.  On the other hand, little helper functions for changing types
are ugly.  (You need the `unnamed function' notation I keep bringing up
every year :-) .)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris