GNOME Bugzilla – Bug 87821
Assignment of handler ids returned by g_signal_new () and friends should be 64-bit clean
Last modified: 2010-10-22 17:05:50 UTC
Handler ids returned by g_signal_new () and friends are being treated as 32-bit quantities. Creating the bug as discussed in the gtk-devel-list. Please also see http://mail.gnome.org/archives/gtk-devel-list/2002-July/msg00041.html Attaching the output of the lint source checker i used. The output contains all the occurances of the warnings.
Changing the version to 2.0.x. Sorry for the mistake.
Created attachment 9770 [details] Log containing all the occurances of the warnings.
Created attachment 9782 [details] The parts of the log I wasn't able to fix easily.
I've fixed the part that is easy to fix; the remainder would need to be fixed by leaving the old field in place and storing the handler ID somewhere else, which is, I think, too ugly to do for the small problem that a potential signal handler wraparound imposes. (Note that the only problems here would also occur on 32-bit platforms, so until most GTK+ usage is on 64-bit platforms, I wouldn't consider this issue urgent.) Wed Jul 10 14:27:14 2002 Owen Taylor <otaylor@redhat.com> * modules/input/gtkimcontextxim.c gtk/gtkcolorsel.c gtk/gtkdialog.c gtk/gtktextbtree.c: Fix some cases where signal connection IDs where being assigned to guint rather than gulong. (part of #87281, Shivram U)
Is this still an issue? It can be easily fixable now as we don't have public members now
Yes, still an issue, and yes, easily fixable now. Just needs somebody to write a patch
Created attachment 171934 [details] [review] Patch This patch fixes all cases of g_signal_connect() and friends being assigned to something different from gulong. It's trivial changes everywhere except for a couple of cases -gtkbutton and gtkimagemenuitem- where the signal handler ID was being stored inside an object using g_object_set_data(). You cannot cast a gulong into a 32-bit gpointer, but since that value was only being used to detect whether the signal handler had already been connected, I changed it for a simpler g_signal_handler_find(), which also allows us to remove a couple of static strings that were otherwise useless. Then there's gailcontainer.c which was storing signal handler IDs for GtkContainer::add and GtkContainer::remove "in case some objects need to remove these handlers", but since no one appears to be using that, I just removed them. Please review and commit. If everything's ok I think we can close the bug.
Review of attachment 171934 [details] [review]: Looks good to me. For what I want, the use cases in GtkButton and GtkImageMenuItem are bad hacks, but that's what it was before anyway.
(In reply to comment #8) > Looks good to me. For what I want, the use cases in GtkButton and > GtkImageMenuItem are bad hacks, but that's what it was before > anyway. If you have a better idea we can still change it :)
ping
Comment on attachment 171934 [details] [review] Patch (In reply to comment #9) > If you have a better idea we can still change it :) I think leave it as-is and re-consider it separately since the patch is fairly large and we don't want to sneak in behavioural changes. I'd say let's do this.