Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Baffled by this ... (casting of function pointers)

Reply
Thread Tools

Baffled by this ... (casting of function pointers)

 
 
Alfonso Morra
Guest
Posts: n/a
 
      08-26-2005
How can this work ?

I have the following declarations in a header:

Header
=========
typedef void (*VFPTR)(void) ;
void FOO_Callback(void*, char*, char*, int, unsigned long, void*,void*);
int bar(int *, char *, VFPTR, void *);

Source
=========
In the C source code, I come accross this line:

bar(&id, name, FOO_Callback, (void *)handle);

This compiles without any problems when compiling as a C program. When
compiling as a C++ source (stricter type checking etc) - the compiler
(unsuprisingly) threw a wobbly. I had to add an explicit "C-style" cast
as ff:

bar(&id, name, (VOID_FUNC)FOO_Callback, (void *)handle);

and the compiler was happy once again.

BUT - wait a minute, HOW can a function (FOO_Callback) declared as a
function returning void and accepting several arguments, be "coerced"
into a function that accepts no arguments?

Here are my questions:

1). Ok it compiles - but does it make sense?
2). Are there any conditions under which one may coerce a function that
requires arguments into one not taking arguments?
3). What does it mean to call a function that expects arguments, with no
arguments - will it even work ?


I hope someone can shed somelight on this baffling piece of "sleight of
hand".

 
Reply With Quote
 
 
 
 
Barry Schwarz
Guest
Posts: n/a
 
      08-26-2005
On Fri, 26 Aug 2005 00:42:00 +0000 (UTC), Alfonso Morra
<(E-Mail Removed)> wrote:

>How can this work ?
>
>I have the following declarations in a header:
>
>Header
>=========
>typedef void (*VFPTR)(void) ;
>void FOO_Callback(void*, char*, char*, int, unsigned long, void*,void*);
>int bar(int *, char *, VFPTR, void *);
>
>Source
>=========
>In the C source code, I come accross this line:
>
>bar(&id, name, FOO_Callback, (void *)handle);


The cast on handle is superfluous if it is a pointer of any type.
Since the prototype for bar is known, any pointer type will be
implicitly converted void* as part of evaluating the arguments.

>
>This compiles without any problems when compiling as a C program. When


Since you should have received a diagnostic on the third argument, you
may have discovered an error in your compiler. It is also possible
that you need to raise the warning level or disable some language
extension.

>compiling as a C++ source (stricter type checking etc) - the compiler
>(unsuprisingly) threw a wobbly. I had to add an explicit "C-style" cast
>as ff:
>
>bar(&id, name, (VOID_FUNC)FOO_Callback, (void *)handle);


I assume you meant (VFPTR) as your cast.

>
>and the compiler was happy once again.
>
>BUT - wait a minute, HOW can a function (FOO_Callback) declared as a
>function returning void and accepting several arguments, be "coerced"
>into a function that accepts no arguments?


A cast is capable of coercing quite a few things, as far as compiler
syntax checking goes. Whether the code will work after the cast is a
completely different issue. Since bar thinks the argument is pointer
to a function taking no arguments, that is how bar would call the
function. When FOO_Callback actually gets control, it will look for
the four arguments and you will invoke undefined behavior.

>
>Here are my questions:
>
>1). Ok it compiles - but does it make sense?


No.

>2). Are there any conditions under which one may coerce a function that
>requires arguments into one not taking arguments?


Only if you never call it. Possibly if you can guarantee the
function will not attempt to look at the arguments.

>3). What does it mean to call a function that expects arguments, with no
>arguments - will it even work ?


Undefined behavior.

>
>
>I hope someone can shed somelight on this baffling piece of "sleight of
>hand".


Sleight of hand implies some skill as a magician. This is just sloppy
code.


<<Remove the del for email>>
 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      08-26-2005
On Fri, 26 Aug 2005 00:42:00 +0000 (UTC), Alfonso Morra
<(E-Mail Removed)> wrote in comp.lang.c:

> How can this work ?
>
> I have the following declarations in a header:
>
> Header
> =========
> typedef void (*VFPTR)(void) ;
> void FOO_Callback(void*, char*, char*, int, unsigned long, void*,void*);
> int bar(int *, char *, VFPTR, void *);
>
> Source
> =========
> In the C source code, I come accross this line:
>
> bar(&id, name, FOO_Callback, (void *)handle);
>
> This compiles without any problems when compiling as a C program. When
> compiling as a C++ source (stricter type checking etc) - the compiler
> (unsuprisingly) threw a wobbly. I had to add an explicit "C-style" cast
> as ff:


The fact that it compiles as a C program indicates one of two things.
The first is that your compiler could be broken. The second, and more
likely, is that your are not operating your compiler in conforming
mode, and it is accepting this as some sort of compiler specific
non-standard extension.

The code is just as illegal in C as it is in C++. Without the cast, a
conforming compiler must issue a diagnostic.

> bar(&id, name, (VOID_FUNC)FOO_Callback, (void *)handle);
>
> and the compiler was happy once again.
>
> BUT - wait a minute, HOW can a function (FOO_Callback) declared as a
> function returning void and accepting several arguments, be "coerced"
> into a function that accepts no arguments?


The C standard specifically allows a pointer to a function of one type
to be converted to a pointer to a function of another type, with a
suitable cast. If the result is later converted back to the original
pointer type, again by the appropriate cast, the reconverted pointer
is guaranteed to point to the original function. So with the cast, it
is perfectly legal in C and, even though it's off-topic here, in C++.
Without the cast it is illegal in both languages.

> Here are my questions:
>
> 1). Ok it compiles - but does it make sense?


With the cast, yes.

> 2). Are there any conditions under which one may coerce a function that
> requires arguments into one not taking arguments?


With the cast, yes.

> 3). What does it mean to call a function that expects arguments, with no
> arguments - will it even work ?


If you call a function through a function pointer of the wrong type,
the behavior is undefined. As far as the language is concerned, there
is no longer a definition of "work" in existence once you produce
undefined behavior.

> I hope someone can shed somelight on this baffling piece of "sleight of
> hand".


There are times when it is useful to deal with generic pointers in C.
A pointer to any type of object can be converted to pointer to void
and back to a pointer of the original type, and will still point to
the original object.

But there is no conversion at all defined between pointers to
functions and any type of pointer to object, not even pointer to void.
Object and function pointers do not exist on the same planet, and
can't be mixed.

So it is quite common to use void(*func)(void) as a generic pointer to
function. As long as the pointer is converted back to the proper type
and called with the correct number and type of arguments, the behavior
is well-defined.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
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
 
Reply With Quote
 
Alfonso Morra
Guest
Posts: n/a
 
      08-26-2005


Alfonso Morra wrote:

> How can this work ?
>
> I have the following declarations in a header:
>
> Header
> =========
> typedef void (*VFPTR)(void) ;
> void FOO_Callback(void*, char*, char*, int, unsigned long, void*,void*);
> int bar(int *, char *, VFPTR, void *);
>
> Source
> =========
> In the C source code, I come accross this line:
>
> bar(&id, name, FOO_Callback, (void *)handle);
>
> This compiles without any problems when compiling as a C program. When
> compiling as a C++ source (stricter type checking etc) - the compiler
> (unsuprisingly) threw a wobbly. I had to add an explicit "C-style" cast
> as ff:
>
> bar(&id, name, (VOID_FUNC)FOO_Callback, (void *)handle);
>
> and the compiler was happy once again.
>
> BUT - wait a minute, HOW can a function (FOO_Callback) declared as a
> function returning void and accepting several arguments, be "coerced"
> into a function that accepts no arguments?
>
> Here are my questions:
>
> 1). Ok it compiles - but does it make sense?
> 2). Are there any conditions under which one may coerce a function that
> requires arguments into one not taking arguments?
> 3). What does it mean to call a function that expects arguments, with no
> arguments - will it even work ?
>
>
> I hope someone can shed somelight on this baffling piece of "sleight of
> hand".
>

Anyone care to add a third view? - I'm none the wiser here since the two
responses I received contradict each other...

 
Reply With Quote
 
Lawrence Kirby
Guest
Posts: n/a
 
      08-26-2005
On Thu, 25 Aug 2005 20:43:33 -0700, Barry Schwarz wrote:

> On Fri, 26 Aug 2005 00:42:00 +0000 (UTC), Alfonso Morra
> <(E-Mail Removed)> wrote:
>
>>How can this work ?
>>
>>I have the following declarations in a header:
>>
>>Header
>>=========
>>typedef void (*VFPTR)(void) ;
>>void FOO_Callback(void*, char*, char*, int, unsigned long, void*,void*);
>>int bar(int *, char *, VFPTR, void *);
>>
>>Source
>>=========
>>In the C source code, I come accross this line:
>>
>>bar(&id, name, FOO_Callback, (void *)handle);

>
> The cast on handle is superfluous if it is a pointer of any type.
> Since the prototype for bar is known, any pointer type will be
> implicitly converted void* as part of evaluating the arguments.


Only pointers to unqualified object or imcomplete types can be converted
implicitly to void *. Function pointers can't nor can pointers with types
like const int * or indeed const void *. However this is a good thing and
attempts at conversions like these should be warned about so the code is
much better without the cast.

Lawrence
 
Reply With Quote
 
Lawrence Kirby
Guest
Posts: n/a
 
      08-26-2005
On Fri, 26 Aug 2005 09:22:10 +0000, Alfonso Morra wrote:

>
>
> Alfonso Morra wrote:
>
>> How can this work ?
>>
>> I have the following declarations in a header:
>>
>> Header
>> =========
>> typedef void (*VFPTR)(void) ;
>> void FOO_Callback(void*, char*, char*, int, unsigned long, void*,void*);
>> int bar(int *, char *, VFPTR, void *);
>>
>> Source
>> =========
>> In the C source code, I come accross this line:
>>
>> bar(&id, name, FOO_Callback, (void *)handle);
>>
>> This compiles without any problems when compiling as a C program. When
>> compiling as a C++ source (stricter type checking etc) - the compiler
>> (unsuprisingly) threw a wobbly. I had to add an explicit "C-style" cast
>> as ff:
>>
>> bar(&id, name, (VOID_FUNC)FOO_Callback, (void *)handle);
>>
>> and the compiler was happy once again.
>>
>> BUT - wait a minute, HOW can a function (FOO_Callback) declared as a
>> function returning void and accepting several arguments, be "coerced"
>> into a function that accepts no arguments?


You can cast pointer types, but ultimately when you call a function the
arguments you call it with must be compatible with its definition.
Essentially that means if you cast a function pointer to a different
function pointer type you must cast it back again before calling the
function.

>> Here are my questions:
>>
>> 1). Ok it compiles - but does it make sense?


No, you're calling the function with the wrong number of arguments, this
has undefined behaviour i.e. the behaviour of your entire program ceases
to be well defined.

>> 2). Are there any conditions under which one may coerce a function that
>> requires arguments into one not taking arguments?


Remember you are not "coercing" functions but pointers to functions. As
noted above you can do this but you must convert the pointer back again
before you call the function.

>> 3). What does it mean
>> to call a function that expects arguments, with no arguments - will it
>> even work ?


Undefined behaviour means anything can happen. It might "work" to some
degree, it might fail completely, you get no guarantees either way.

>> I hope someone can shed somelight on this baffling piece of "sleight of
>> hand".


The code is simply broken.

> Anyone care to add a third view? - I'm none the wiser here since the two
> responses I received contradict each other...


How so?

Lawrence

 
Reply With Quote
 
Alfonso Morra
Guest
Posts: n/a
 
      08-26-2005


Lawrence Kirby wrote:
> On Fri, 26 Aug 2005 09:22:10 +0000, Alfonso Morra wrote:
>
>
>>
>>Alfonso Morra wrote:
>>
>>
>>>How can this work ?
>>>
>>>I have the following declarations in a header:
>>>
>>>Header
>>>=========
>>>typedef void (*VFPTR)(void) ;
>>>void FOO_Callback(void*, char*, char*, int, unsigned long, void*,void*);
>>>int bar(int *, char *, VFPTR, void *);
>>>
>>>Source
>>>=========
>>>In the C source code, I come accross this line:
>>>
>>>bar(&id, name, FOO_Callback, (void *)handle);
>>>
>>>This compiles without any problems when compiling as a C program. When
>>>compiling as a C++ source (stricter type checking etc) - the compiler
>>>(unsuprisingly) threw a wobbly. I had to add an explicit "C-style" cast
>>>as ff:
>>>
>>>bar(&id, name, (VOID_FUNC)FOO_Callback, (void *)handle);
>>>
>>>and the compiler was happy once again.
>>>
>>>BUT - wait a minute, HOW can a function (FOO_Callback) declared as a
>>>function returning void and accepting several arguments, be "coerced"
>>>into a function that accepts no arguments?

>
>
> You can cast pointer types, but ultimately when you call a function the
> arguments you call it with must be compatible with its definition.
> Essentially that means if you cast a function pointer to a different
> function pointer type you must cast it back again before calling the
> function.
>
>
>>>Here are my questions:
>>>
>>>1). Ok it compiles - but does it make sense?

>
>
> No, you're calling the function with the wrong number of arguments, this
> has undefined behaviour i.e. the behaviour of your entire program ceases
> to be well defined.
>
>
>>>2). Are there any conditions under which one may coerce a function that
>>>requires arguments into one not taking arguments?

>
>
> Remember you are not "coercing" functions but pointers to functions. As
> noted above you can do this but you must convert the pointer back again
> before you call the function.
>
>
>>>3). What does it mean
>>>to call a function that expects arguments, with no arguments - will it
>>>even work ?

>
>
> Undefined behaviour means anything can happen. It might "work" to some
> degree, it might fail completely, you get no guarantees either way.
>
>
>>>I hope someone can shed somelight on this baffling piece of "sleight of
>>>hand".

>
>
> The code is simply broken.
>
>
>>Anyone care to add a third view? - I'm none the wiser here since the two
>>responses I received contradict each other...

>
>
> How so?
>
> Lawrence
>


Thanks Lawrence, your posyt clarifies things up. BTW, I posted my
"request for disambiguation" before your last post (i.e. only Barry and
Jack had responded, and they each had a different P.O.V).

What you've said so far ties in with what Jack says - and it does stand
to reason if one pauses to think carefully at what is actually been done.

 
Reply With Quote
 
Denis Kasak
Guest
Posts: n/a
 
      08-26-2005
Alfonso Morra wrote:
>
> Thanks Lawrence, your posyt clarifies things up. BTW, I posted my
> "request for disambiguation" before your last post (i.e. only Barry and
> Jack had responded, and they each had a different P.O.V).
>
> What you've said so far ties in with what Jack says - and it does stand
> to reason if one pauses to think carefully at what is actually been done.


Actually, all three posters (Barry, Jack and Lawrence) have told you the
same thing. They all stated that you must change the pointer back before
calling the function through it and that failing to do so invokes
undefined behaviour. Why would you think Barry said something different?

-- Denis

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Baffled =?Utf-8?B?UGFt?= Wireless Networking 21 01-22-2006 09:12 PM
Absolutely baffled - card not seeing network =?Utf-8?B?QW5ndXM=?= Wireless Networking 4 10-30-2005 10:04 PM
Baffled by Wireless Connection =?Utf-8?B?UGFt?= Wireless Networking 2 03-07-2005 01:13 AM
Baffled by OSPF type shown in debug Jose Cisco 2 10-29-2004 12:17 AM
baffled... Lloyd Dupont ASP .Net 2 09-01-2004 11:51 PM



Advertisments