Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!tank!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: Function-types: compatability, and typedefs Message-ID: <19361@mimsy.UUCP> Date: 1 Sep 89 07:05:25 GMT References: Distribution: comp Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 34 In article kers@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 , you can always (by the proposed standard, at least) cast it to some other function pointer type () 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@mimsy.umd.edu Path: uunet!mimsy!chris