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