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