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
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 <email@example.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]
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
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
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
If you have a better idea we can still change it :)
Comment on attachment 171934 [details] [review]
(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.