Xref: utzoo comp.lang.c:35153 comp.std.c:4112
Newsgroups: comp.lang.c,comp.std.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: (void *) to function pointer
Message-ID: <1991Jan11.180143.8574@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <1991Jan9.000809.9152@brolga.cc.uq.oz.au> <1991Jan10.204613.27415@ingres.Ingres.COM>
Date: Fri, 11 Jan 1991 18:01:43 GMT

In article <1991Jan10.204613.27415@ingres.Ingres.COM> jab@crane.Ingres.COM (jeff bowles) writes:
>>... state that a (void *)
>>is only guaranteed to be large enough to hold a pointer to any *data*
>>object) and is not suitable for a generic function pointer.
>
>It was my impression that a "void *" had to be large enough to contain
>any other kind of pointer...

Nope; function pointers are excluded... although there is a promise that
you can convert one flavor of function pointer to another without losing
information, so you don't really need `void *' for that -- all function
pointers are large enough to contain each other.

>and that there were no rules that said that
>you had to be able to dereference a "void *" without converting it to
>some other pointer type first.

You can dereference a `void *' -- I had thought you couldn't, but it seems
to be permitted -- but the "value" you get is of type `void', which is
useless.

>Then "void *" would have to be at least that large. There is no guarantee
>that conversion to any other type of pointer and back again retains all
>information. (I heard that they put in a hack so this would be true for
>"char *" also, but "say it ain't so!")

`void *' and `char *' are required to use the same representation.  There
are too many places where library functions logically should take parameters
of type `void *' but historically take `char *'.
-- 
If the Space Shuttle was the answer,   | Henry Spencer at U of Toronto Zoology
what was the question?                 |  henry@zoo.toronto.edu   utzoo!henry