473,320 Members | 2,177 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

cast function pointer to void*

*Hope this thread doesn't violate this group's rule*

I found the following code in the GNOME's glib-2.12 source:

/* In gclosure.c */
GClosure*
g_cclosure_new (GCallback callback_func,
gpointer user_data,
GClosureNotify destroy_data)
{
......
/* ((GCClosure*) closure)->callback is of type gpointer */
((GCClosure*) closure)->callback = (gpointer) callback_func;
}

Here a GCallback is cast to a gpointer type. The definition of
GCallback and gpointer are as follows:
typedef void (*GCallback) (void); /* in gclosure.h */
typedef void* gpointer; /* in gtypes.h */

So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior. I wonder if
the glib practice is preferable.

Nov 22 '06 #1
10 11074
WaterWalk wrote:
*Hope this thread doesn't violate this group's rule*

I found the following code in the GNOME's glib-2.12 source:
[...]
So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior.
It's a constraint violation, actually, meaning it might not compile, or
if it does compile, the /entire/ program is outside of the scope of the
C standard (even if the conversion would never actually be performed).
I wonder if
the glib practice is preferable.
Preferable to what? There's simply no way in standard C to reliably
convert function pointers to object pointers, so if there is a
legitimate reason to do so (I don't know if there is a good reason
here), it must be done using an implementation-specific extension.

Nov 22 '06 #2
"WaterWalk" <to********@163.comwrote:
*Hope this thread doesn't violate this group's rule*
The code is off-topic, but the question you ask about it - basically,
_is_ this ISO C - is on-topic.
/* In gclosure.c */
GClosure*
g_cclosure_new (GCallback callback_func,
gpointer user_data,
GClosureNotify destroy_data)
{
......
/* ((GCClosure*) closure)->callback is of type gpointer */
((GCClosure*) closure)->callback = (gpointer) callback_func;
}

Here a GCallback is cast to a gpointer type. The definition of
GCallback and gpointer are as follows:
typedef void (*GCallback) (void); /* in gclosure.h */
typedef void* gpointer; /* in gtypes.h */

So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior. I wonder if
the glib practice is preferable.
Yes, it's undefined behaviour; and therefore, no, it's not preferable.
Nor is it necessary, since ISO C requires that all function pointer
types can be converted to and from one another without loss of
information.

Richard
Nov 22 '06 #3
Harald van Dijk wrote:
WaterWalk wrote:
*Hope this thread doesn't violate this group's rule*

I found the following code in the GNOME's glib-2.12 source:
[...]
So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior.

It's a constraint violation, actually, meaning it might not compile, or
if it does compile, the /entire/ program is outside of the scope of the
C standard (even if the conversion would never actually be performed).
Actually... I know it's treated as a constraint violation by multiple
compilers, but I can't seem to find any wording in the standard that
says so. I'd appreciate it if anyone could point it out.

Nov 22 '06 #4
On 22 Nov 2006 07:03:15 -0800, "WaterWalk" <to********@163.comwrote
in comp.lang.c:
*Hope this thread doesn't violate this group's rule*

I found the following code in the GNOME's glib-2.12 source:

/* In gclosure.c */
GClosure*
g_cclosure_new (GCallback callback_func,
gpointer user_data,
GClosureNotify destroy_data)
{
......
/* ((GCClosure*) closure)->callback is of type gpointer */
((GCClosure*) closure)->callback = (gpointer) callback_func;
}

Here a GCallback is cast to a gpointer type. The definition of
GCallback and gpointer are as follows:
typedef void (*GCallback) (void); /* in gclosure.h */
typedef void* gpointer; /* in gtypes.h */

So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior. I wonder if
the glib practice is preferable.
Unfortunately, there is a lot of code that is based on the fact that
on many implementations pointers to functions and pointers to void
have the same size and number of value bits. It is, was, and always
has been sloppy programming with no real justification whatsoever.

This behavior is now required in both the Windows and POSIX APIs, for
example.

But I don't understand your question. You post one code sample which
you state if from glib source, then ask is the glib practice is
preferable. Preferable to what alternative?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 22 '06 #5
Jack Klein wrote:
Unfortunately, there is a lot of code that is based on the fact that
on many implementations pointers to functions and pointers to void
have the same size and number of value bits. It is, was, and always
has been sloppy programming with no real justification whatsoever.

This behavior is now required in both the Windows and POSIX APIs, for
example.
As far as I remember, on IA-64/Linux, object pointers are 64 bits wide
while function pointers are 128 bits wide.

cf. http://www.gelato.unsw.edu.au/archiv...0201/2679.html

"On IA64 and PPC64 the function pointer does not reference the function
itself, instead it points to a function descriptor. The function
descriptor contains a pointer to the function code plus additional data
such as a pointer to the global data to be used when the function is
called. This is mandated by the architecture software ABI."
Nov 22 '06 #6
In article <li********************************@4ax.com>,
Jack Klein <ja*******@spamcop.netwrote:
>On 22 Nov 2006 07:03:15 -0800, "WaterWalk", who's native language is probably not English, <to********@163.comwrote
in comp.lang.c:
....
>So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior. I wonder if
the glib practice is preferable.
....
>But I don't understand your question. You post one code sample which
you state if from glib source, then ask is the glib practice is
preferable. Preferable to what alternative?
I think that he was using "preferable" when he meant "desirable".

Give the guy a break!

Nov 22 '06 #7
Spoon <de*****@localhost.comwrites:
[...]
As far as I remember, on IA-64/Linux, object pointers are 64 bits wide
while function pointers are 128 bits wide.
No, all pointers are 64 bits wide (at least on the IA-64/Linux system
I use).
cf. http://www.gelato.unsw.edu.au/archiv...0201/2679.html

"On IA64 and PPC64 the function pointer does not reference the function
itself, instead it points to a function descriptor. The function
descriptor contains a pointer to the function code plus additional data
such as a pointer to the global data to be used when the function is
called. This is mandated by the architecture software ABI."
If a function pointer points to a descriptor, there's no reason for it
to be bigger than an object pointer.

--
Keith Thompson (The_Other_Keith) 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.
Nov 22 '06 #8

Kenny McCormack wrote:
In article <li********************************@4ax.com>,
Jack Klein <ja*******@spamcop.netwrote:
On 22 Nov 2006 07:03:15 -0800, "WaterWalk", who's native language is probably not English, <to********@163.comwrote
in comp.lang.c:
...
So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior. I wonder if
the glib practice is preferable.
...
But I don't understand your question. You post one code sample which
you state if from glib source, then ask is the glib practice is
preferable. Preferable to what alternative?

I think that he was using "preferable" when he meant "desirable".

Give the guy a break!
Yes, I should have used "desirable" rather than "preferable". Sorry for
this misuse of word.

When I saw this code in glib, I was confused: Glib is a widely-used
library. It's code must(at least I think) be reviewed thoroughly. Yet
this cast I posted is undefined. I just don't understand why the glib
developers use such an extension, since it's not necessary, as Richart
Bos previously said.

Hope this clarifies my question. :)

Nov 23 '06 #9
WaterWalk wrote:
When I saw this code in glib, I was confused: Glib is a widely-used
library. It's code must(at least I think) be reviewed thoroughly. Yet
this cast I posted is undefined. I just don't understand why the glib
developers use such an extension, since it's not necessary, as Richart
Bos previously said.
Well, all of the systems that Glib runs on, support this extension.

Probably what happened is that the Glib developers did not
realise, or did not care, that it was non-standard. Perhaps
you could post on a Glib mailing list; they might be able to
explain exactly why they chose this route.

Nov 23 '06 #10
"WaterWalk" <to********@163.comwrites:
[...]
>In article <li********************************@4ax.com>,
Jack Klein <ja*******@spamcop.netwrote:
>On 22 Nov 2006 07:03:15 -0800, "WaterWalk", who's native language
is probably not English, <to********@163.comwrote in
comp.lang.c:
[...]
>So the result is that a (void (*)(void)) is cast to (void*). However a
search of this group and c99 standard indicates that casting a
function pointer to a void pointer is undefined behavior. I wonder if
the glib practice is preferable.
...
>But I don't understand your question. You post one code sample which
you state if from glib source, then ask is the glib practice is
preferable. Preferable to what alternative?
[...]
Yes, I should have used "desirable" rather than "preferable". Sorry for
this misuse of word.

When I saw this code in glib, I was confused: Glib is a widely-used
library. It's code must(at least I think) be reviewed thoroughly. Yet
this cast I posted is undefined. I just don't understand why the glib
developers use such an extension, since it's not necessary, as Richart
Bos previously said.
I suspect that GLib is not intended to be completely portable to all
possible conforming C implementations. As far as I know, *most* C
compilers do support conversions between function pointers and void*.
Possibly GLib is merely intended to be portable to just those
compilers. (The phrase "as far as I know" may be assumed to imply a
wealth of ignorance; there are plenty of C compilers I'm not familiar
with.)

But as you say, it probably wasn't necessary to use this particular
extension; GLib could have used, say, void (*)(void) as a generic
pointer-to-function type.

--
Keith Thompson (The_Other_Keith) 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.
Nov 23 '06 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Patrick Guio | last post by:
Dear all, I have a C function that returns a void pointer (void *). This object pointer is actually a pointer to function. I have the following declarations: void *pobj; double...
5
by: Dave Townsend | last post by:
Hi, I'm trying to port a piece of code from Windows to Linux, the following segment illustrates the coding problemI have: Under Linux, the reinterpret_cast line doesn't compile, the compiler...
3
by: Kobu | last post by:
Does the C standard guarantee that a value of type (T*) casted to (void*) then back to (T*) later on, will be equal to the original value?
9
by: Frederick Gotham | last post by:
Let's assume that we're working on the following system: CHAR_BIT == 8 sizeof( char* ) == 4 (i.e. 32-Bit) Furthermore, lets assume that the memory addresses are distributed as follows: ...
7
by: llothar | last post by:
When i use -W4 on visual c 7.0 i get warning C4054 translator1.c(1703) : warning C4054: 'type cast' : from function pointer 'void * (__cdecl *)(se_agent *)' to data pointer 'void *'...
5
by: johnbrown105 | last post by:
Hello All, I did try searching the archives, but the topics seemed to be mostly about base and derived classes. I have reached Chapter 8 in Bruce Eckel's "Thinking in C++ 2nd Edition Vol....
1
by: etienne | last post by:
Hello all, i'm experimenting a problem in trying to cast a char * variable to a pointer to a function. My problem is that I want to execute functions in threads, using the pthread_create...
3
by: Bartc | last post by:
I have a variable like this: int *p; Sometimes this points to an int location containing the address of a void(void) function. How can I cast it so that I can call that function? I've...
7
by: * Tong * | last post by:
Hi, I couldn't figure out how to properly type cast in this case: $ cat -n type_cast.c 1 #include <stdio.h> 2 3 typedef unsigned char Byte; 4 typedef signed char Small_Int; 5
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.