Re: Some pointer quiestions again

Chris Torek wrote:
> In article <1117569067.744233.160900@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Robert Gamble <rgamble99@xxxxxxxxx> wrote:
> >Correct. A function pointer can be converted to a void pointer [1] but
> >cannot portably be converted back again. ...
>
> You can do the conversion (in either direction) with a cast:
>
> void f(void (*fp)(void)) {
> void *p = (void *)fp;
> ...
> }
>
> but the result is not necessarily useful. For instance, older x86
> implementations have models in which "char *"/"void *" is 32 bits
> long, while "void (*)(void)" is only 16 bits; and more models in
> which "char *"/"void *" is 16 bits long, but "void (*)(void)" is
> 32 bits. Clearly, in any system on which one conversion preserves
> all the bits (by going from 16 bits to 32 bits), the opposite
> conversion destroys some bits (by going from 32 to 16).
>
> Since both systems exist, both conversions destroy some bits on
> some systems. (That is, suppose System A has 16-bit function
> pointers and 32-bit data pointers; and System B has 32-bit function
> pointers and 16-bit data pointers. On System A, going from function
> to data preserves everything, but going from data to function wipes
> out bits. So the [1989] C standard could have attempted to mandate
> that "function to data preserves bits" -- but then System B loses
> out, because on System B, it is the function-to-data conversion
> that loses bits, while the data-to-function conversion preserves
> them.)
>
> >[1] I am not sure that a function pointer can even be converted to a
> >void pointer reliably, if not then there would appear to be no portable
> >way to print the value of a function pointer.
>
> This is indeed the case.
>
> I have seen a proposal for a "%P" (uppercase P) conversion to print
> a function pointer, to solve this problem. Of course, the output
> for "%p" (lowercase p) is already implementation-defined anyway, and
> printing "void *" data pointers is thus of limited usefuless. There
> seems to be no great clamor for printing function pointers.

Thank you very much for your detailed clarification. I had long
suspected that this was the case but hadn't given it too much thought.
Your explanation makes a lot of sense and clears this up for me.

Robert Gamble

.

Relevant Pages

  • Re: Function Pointers
    ... Just a heads-up - you don't need the cast. ... lossless conversion between void * and function pointers, ... I thought you couldn't have a generic function pointer like the 'void ... there is no generic function pointer type. ...
    (comp.lang.c)
  • Re: cast to void *
    ...     return 0; ... Except that conversion between void* and struct tm is a constraint ... Conversion between void* and a function pointer, ...
    (comp.lang.c)
  • Re: bug in visual studio .net 2003 - breakpoints and memcpy
    ... According to ANSI C and standard C++, there is no standard conversion from a ... function pointer to void*, and vice versa. ... Both Win32 and Posix define the conversion. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: bug in visual studio .net 2003 - breakpoints and memcpy
    ... In any case I think arguing about the standard is besides the point. ... prescribe that the conversion must work. ... > A function pointer may have a special format on some architectures ... second restriction on IA64. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Some pointer quiestions again
    ... A function pointer can be converted to a void pointer but ... You can do the conversion with a cast: ... >void pointer reliably, if not then there would appear to be no portable ...
    (comp.lang.c)