Re: [gtk-list] Re: Apprarently simple signal/event question

[Havoc Pennington <hp redhat com>]

"Peter  Garner" <peter.garner@toward.com> writes: 
> 
> Really?  Thanks for the heads up!!!

The return value has to be stored in memory somewhere; if the compiler
thinks there is no return value when invoking the function pointer it
doesn't have to make that memory. But if the function being invoked
has a return value it will put the return value there anyway.

>  Upon what machine type 
> do you usually program?  I mostly use intel, and although it 
> is a terrible coding practice, just for warning purposes on
> WHICH machine type returning a value where none is expected 
> would cause any problems?  
> 

No clue, I would expect it to cause problems on any machine.
 
> Hehe, Havoc, I think he meant he was surprised by the fact
> that the compiler did not emit an error about improper
> 3rd argument type in the argument list to "gtk_signal_connect".
> Of course I could be wrong, his original question was a bit
> unclear as to what he meant by "works".  Isn't the reason
> that the gtk_signal_connect function works that the
> GTK_SIGNAL_FUNC( signalblahblah ) macro casts the
> 'signalblahblah' pointer to the expected pointer type?
> 

Yes the function pointer is cast, so you don't get warnings about the
type mismatch.
 
> I am sorry, I really had a hard time understanding what you
> meant here.  I are you saying that C has no way of
> determining the function type of a function pointer?  If
> that is so, then why bother with the GTK_SIGNAL_FUNC macro
> in the first place?  BTW, I have done little or no C
> programming.  I have coded almost exclusively in C++ for
> the last 13 years, so please pardon me if what I am asking
> seems stupid from a C programmers point of view.
> 

C++ is pretty much the same here (unless you use RTTI).

C knows the type of a function pointer at compile time, but it doesn't
know it at run time. In this case you need to know at run time in
order to signal an error.

Havoc