Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: Ptr to func doesn't like casting?? Message-ID: <4767@utzoo.UUCP> Date: Tue, 11-Dec-84 15:23:42 EST Article-I.D.: utzoo.4767 Posted: Tue Dec 11 15:23:42 1984 Date-Received: Tue, 11-Dec-84 15:23:42 EST References: <13900010@acf4.UUCP> <4688@utzoo.UUCP>, <10103@watmath.UUCP> Organization: U of Toronto Zoology Lines: 33 > I always had the impression K&R didn't make an exception for function > pointers when it stated that different pointer types can be cast into > each other. Oh well. K&R didn't, but then we all know that casts were a pretty late addition to C and K&R didn't really describe them very well at all. > What does the ANSI committee suggest for a generic function pointer? Or > does (void *) still work? They don't have any specific suggestion that I've seen. "void *" is the generic pointer-to-object, but functions are not objects. > Using a union is not always a practical solution. ... Agreed. Note that you *can* cast pointers to functions around "among themselves", so to speak; it's just that you can't mix them with pointers to objects without trouble. So you need to start thinking about unions only in really unusual situations. The example you give (passing a generic "pointer to function") isn't a problem here, although it would be nice if there were a function-pointer equivalent of "void *". > Are there machines which cannot cast a function pointer into another > pointer (e.g. (void *)) and back? After all, you can cast any pointer > into an implementation-dependant integral type and back without loss > of information... I'm not aware of any... but they may exist. Casting pointers to the proper integral type and back is always workable; perhaps this is the thing to do in dire extremity. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry