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



Hi All!

>- no return value - returning a value when "void" is 
>expected usually causes memory corruption 


Really?  Thanks for the heads up!!!  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?  


>>gtk_signal_connect( GTK_OBJECT(MyWindow),
>>                    "delete_event",
>>                    GTK_SIGNAL_FUNC( signalblahblah ),
>>                    NULL );
>>
>>
>>It occurs to me that based on what the docs say, that I 
>>should get an error for connecting a signal handler to what 
>>is obviously an event.  I don't, the code works, and I've 
>>seen in numerous other pieces of code.  
>
>The code works as long as you don't try to use the gpointer, 

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?

>There is no way in C to ask for the type of a callback, so 
>no way for GTK+ to check that type.  So you simply have to 
>get it right.  If you get the wrong type, sometimes it's 
>harmless, sometimes you corrupt memory.  ;-) 

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]