function * = void *

[Bill Pursell]

The following code generates a compiler warning
when compiled with gcc -pedantic:

typedef (*FUNC)(int);
FUNC f;

void *
get_f(void)
{
return &f;
}

int main(void)
{
FUNC fp;
fp = (FUNC)get_f();
return 0;
}
~

The warning is:
a.c: In function `main':
a.c:14: warning: ISO C forbids conversion of object pointer to function
pointer type

If I remove the cast, the warning is:
a.c: In function `main':
a.c:14: warning: ISO C forbids assignment between function pointer and
`void *'
Surely I can use this construction? Can I safely ignore the warning?
I'd prefer to keep -pedantic in my CFLAGS---how can I
correctly suppress the warning?

Or am I doing something wrong?

[Ben Pfaff]

"Bill Pursell" <bi**********@g mail.com> writes:

typedef (*FUNC)(int);
FUNC f;

void *
get_f(void)
{
return &f;
}
[...]
Or am I doing something wrong?

Yes. The standard doesn't allow conversion between function and
object pointers. Why not change get_f() to return a function
pointer? It doesn't have to be the *correct* kind of function
pointer: casts from one kind of function pointer to another are
allowed and well-defined, as long as you don't actually call a
function through an incompatible function pointer.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Gordon Burditt]

>The following code generates a compiler warning

when compiled with gcc -pedantic:

typedef (*FUNC)(int);
FUNC f;

void *
get_f(void)
{
return &f;
}

int main(void)
{
FUNC fp;
fp = (FUNC)get_f();
return 0;
}
~

The warning is:
a.c: In function `main':
a.c:14: warning: ISO C forbids conversion of object pointer to function
pointer type

If I remove the cast, the warning is:
a.c: In function `main':
a.c:14: warning: ISO C forbids assignment between function pointer and
`void *'
Surely I can use this construction?
There is no guarantee that a function pointer can FIT in a void *
without truncating it. On Intel x86 platforms, there are medium
and compact models where the size of a function pointer is not the
same as that of a data pointer (on one the data pointer is larger,
on the other the function pointer is larger).

It wouldn't surprise me if there will be new platforms where there
are function and data pointers of 64-bits (or perhaps 48 bits) and
32-bits. The issue isn't just ancient hardware.

You *can* use the construct fflush(main) if you can find even one
platform it works on. I don't know of any country where you would
be arrested for that. I don't understand why this is an issue.
Can I safely ignore the warning?
It depends on how portable you want your code to be, and what
platform you are actually running on. You are writing code
which makes invalid assumptions and the problem isn't likely
to just be ancient hardware.
I'd prefer to keep -pedantic in my CFLAGS---how can I
correctly suppress the warning?

Or am I doing something wrong?

According to ANSI C, you are doing something wrong.

Gordon L. Burditt

[Bill Pursell]

Ben Pfaff wrote:

"Bill Pursell" <bi**********@g mail.com> writes:

typedef (*FUNC)(int);
FUNC f;

void *
get_f(void)
{
return &f;
}

[...]

Or am I doing something wrong?

Yes. The standard doesn't allow conversion between function and
object pointers. Why not change get_f() to return a function
pointer? It doesn't have to be the *correct* kind of function
pointer: casts from one kind of function pointer to another are
allowed and well-defined, as long as you don't actually call a
function through an incompatible function pointer.

This may be OT, as it's system specific, but how am I supposed
to use dlopen()? It's prototyped to return a void *. Should I do
something like: (doesn't compile)

typedef int (*FUNC)(int);
FUNC f;

typedef FUNC *(F_GETTER)(voi d);

void * dlopen(void) { return &f; }

int main(void)
{
FUNC fp;
fp = ((F_GETTER)dlop en)();
}

[Bill Pursell]

Bill Pursell wrote:

Ben Pfaff wrote:

"Bill Pursell" <bi**********@g mail.com> writes:

typedef (*FUNC)(int);
FUNC f;

void *
get_f(void)
{
return &f;
}

[...]

Or am I doing something wrong?

Yes. The standard doesn't allow conversion between function and
object pointers. Why not change get_f() to return a function
pointer? It doesn't have to be the *correct* kind of function
pointer: casts from one kind of function pointer to another are
allowed and well-defined, as long as you don't actually call a
function through an incompatible function pointer.

This may be OT, as it's system specific, but how am I supposed
to use dlopen()? It's prototyped to return a void *. Should I do
something like: (doesn't compile)

typedef int (*FUNC)(int);
FUNC f;

typedef FUNC *(F_GETTER)(voi d);

void * dlopen(void) { return &f; }

int main(void)
{
FUNC fp;
fp = ((F_GETTER)dlop en)();
}

oops, I meant dlsym() in the above.

[William Ahern]

On Wed, 21 Jun 2006 12:01:08 -0700, Bill Pursell wrote:

Bill Pursell wrote:

Ben Pfaff wrote:

> Yes. The standard doesn't allow conversion between function and
> object pointers. Why not change get_f() to return a function pointer?
> It doesn't have to be the *correct* kind of function pointer: casts
> from one kind of function pointer to another are allowed and
> well-defined, as long as you don't actually call a function through an
> incompatible function pointer.
This may be OT, as it's system specific, but how am I supposed to use
dlopen()? It's prototyped to return a void *. Should I do something
like: (doesn't compile)

<snip> oops, I meant dlsym() in the above.

dlopen() and dlsym() aren't standard C. They're Unix specific. It's a fair
bet that if they're available on your platform, then explicitly casting
between function pointers and void pointers will work as desired. But such
C code, as well as the use of those interfaces, isn't portable outside of
Unix. Here's what SUSv3 has to say about the issue:

RATIONALE

The ISO C standard does not require that pointers to functions can be
cast back and forth to pointers to data. Indeed, the ISO C standard does
not require that an object of type void * can hold a pointer to a
function. Implementations supporting the XSI extension, however, do
require that an object of type void * can hold a pointer to a function.
The result of converting a pointer to a function into a pointer to
another data type (except void *) is still undefined, however. Note that
compilers conforming to the ISO C standard are required to generate a
warning if a conversion from a void * pointer to a function pointer is
attempted as in:

fptr = (int (*)(int))dlsym( handle, "my_functio n");

Due to the problem noted here, a future version may either add a new
function to return function pointers, or the current interface may be
deprecated in favor of two new functions: one that returns data pointers
and the other that returns function pointers.

Source: http://www.opengroup.org/onlinepubs/...ons/dlsym.html

[Keith Thompson]

"Bill Pursell" <bi**********@g mail.com> writes:

Ben Pfaff wrote:

"Bill Pursell" <bi**********@g mail.com> writes:

> typedef (*FUNC)(int);
> FUNC f;
>
> void *
> get_f(void)
> {
> return &f;
> }

[...]

> Or am I doing something wrong?

Yes. The standard doesn't allow conversion between function and
object pointers. Why not change get_f() to return a function
pointer? It doesn't have to be the *correct* kind of function
pointer: casts from one kind of function pointer to another are
allowed and well-defined, as long as you don't actually call a
function through an incompatible function pointer.

This may be OT, as it's system specific, but how am I supposed
to use dlopen()? It's prototyped to return a void *.

<OT>
According to the man page, dlopen() returns an opaque "handle" for the
dynamic library, not something to be used as a function pointer. It's
dlsym() that's the problem.
</OT>

An implementation may support conversion from void* to
pointer-to-function as an extension. If you have a function that
returns a void* and expects you to use it as a pointer-to-function,
that function would only be usable with an implementation that
supports such an extension. Any code that depends on such an
extension is obviously non-portable; if you invoke the compiler with
an option that asks it to warn you about non-portable code, it's going
to warn you about this.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jaysome]

On Wed, 21 Jun 2006 18:22:35 -0000, go***********@b urditt.org (Gordon
Burditt) wrote:

The following code generates a compiler warning
when compiled with gcc -pedantic:

typedef (*FUNC)(int);
FUNC f;

void *
get_f(void)
{
return &f;
}

int main(void)
{
FUNC fp;
fp = (FUNC)get_f();
return 0;
}
~

The warning is:
a.c: In function `main':
a.c:14: warning: ISO C forbids conversion of object pointer to function
pointer type

If I remove the cast, the warning is:
a.c: In function `main':
a.c:14: warning: ISO C forbids assignment between function pointer and
`void *'
Surely I can use this construction?

There is no guarantee that a function pointer can FIT in a void *
without truncating it.

If that's the case, how should I printf() the value of a function
pointer?

#include <stdio.h>
typedef void (*func_ptr_type )(void);
int main(void)
{
func_ptr_type func_ptr = NULL;
printf("val = %p\n", (void *)func_ptr);
return 0;
}

The "%p" conversion specifier requires a (void*), but if I convert a
function pointer to (void*) and that gets "truncated" , isn't there a
serious flaw in the standard?

--
jay

[Keith Thompson]

jaysome <ja*****@spamco p.net> writes:

On Wed, 21 Jun 2006 18:22:35 -0000, go***********@b urditt.org (Gordon
Burditt) wrote:

[...]

There is no guarantee that a function pointer can FIT in a void *
without truncating it.

If that's the case, how should I printf() the value of a function
pointer?

#include <stdio.h>
typedef void (*func_ptr_type )(void);
int main(void)
{
func_ptr_type func_ptr = NULL;
printf("val = %p\n", (void *)func_ptr);
return 0;
}

The "%p" conversion specifier requires a (void*), but if I convert a
function pointer to (void*) and that gets "truncated" , isn't there a
serious flaw in the standard?

There's no portable way to print the value of a function pointer,
other than by aliasing it to an array of unsigned char and printing
the bytes.

I don't think it's a serious flaw; how often do you need to print the
value of a function pointer?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Simon Biber]

jaysome wrote:

On Wed, 21 Jun 2006 18:22:35 -0000, go***********@b urditt.org (Gordon
Burditt) wrote:

There is no guarantee that a function pointer can FIT in a void *
without truncating it.
If that's the case, how should I printf() the value of a function
pointer?

Byte by byte.
#include <stdio.h>
typedef void (*func_ptr_type )(void);
int main(void)
{
func_ptr_type func_ptr = NULL;
printf("val = %p\n", (void *)func_ptr);
return 0;
}
Try this:

#include <stdio.h>
#include <limits.h>
typedef int (*func_ptr_type )(void);
int main(void)
{
func_ptr_type func_ptr = main;
size_t i;
printf("val = 0x");
for(i = 0; i < sizeof func_ptr; i++)
{
printf("%0*X",
(CHAR_BIT + 3) / 4,
(unsigned)((uns igned char *)&func_ptr)[i]);
}
printf("\n");
return 0;
}

This compiles cleanly and prints val = 0x50104000
on my system.
The "%p" conversion specifier requires a (void*), but if I convert a
function pointer to (void*) and that gets "truncated" , isn't there a
serious flaw in the standard?

Not really. The %p specifier is only for printing void* pointers. It so
happens that all object pointers can be converted to unique void* values.

--
Simon.