Function-types: compatability, and typedefs
Larry Miller
lmiller at venera.isi.edu
Sat Sep 2 04:14:54 AEST 1989
In article <19361 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>
>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.
This is my interpretation also, but GNU, in particular, disallows
this. Since my copy of the draft standard is very old (Nov, 1985),
could someone refer to a specific section in the latest draft?
Also, it's my interpretation that in a function taking a
(void *), that this would work, without cast, for anything *.
Specifically, qsort:
void qsort(void *base, size_t n, size_t width,
int (*f)(const void *, const void *));
Can be passed a char ** as the first element WITHOUT specifically
casting to void * (as long as the prototype is in scope).
Larry Miller lmiller at venera.isi.edu (no uucp)
USC/ISI 213-822-1511
4676 Admiralty Way
Marina del Rey, CA. 90292
More information about the Comp.lang.c
mailing list