After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 593559 - GCC warning due to lack of emitted cast when passing GTK callback function pointer
GCC warning due to lack of emitted cast when passing GTK callback function po...
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: general
0.7.x
Other Linux
: Low minor
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks: 688447
 
 
Reported: 2009-08-30 14:38 UTC by Martin Olsson
Modified: 2018-05-17 06:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Olsson 2009-08-30 14:38:35 UTC
The following Vala testcase results in a GCC warning:

public class Program
{
        public bool f (Gtk.TreeSelection selection, Gtk.TreeModel model, Gtk.TreePath path, bool path_currently_selected)
        {
                return true;
        }
        public void run ()
        {
                var treeview = new Gtk.TreeView ();
                treeview.get_selection().set_select_function (f, null);
        }
        public static void main(string[] args)
        {
                new Program ().run ();
        }
}

As a hack / workaround; the warning goes away if I cast f to TreeSelectionFunc before passing it to set_select_function().

Actual behavior: Vala compilation finishes with no warnings and then GCC find a problem with the generated code and prints a GCC warning for it.

Expected behavior: Vala should verify if the signature of "f" and if it's correct it should emit GtkTreeSelectionFunc cast, if f does not have the correct signature Vala should print a Vala warning/error.

To fix this bug the following tiny change needs to be made to the generated output:


--- main.c	2009-08-30 16:28:38.000000000 +0200
+++ main.c.fixed	2009-08-30 16:26:37.000000000 +0200
@@ -71,17 +71,17 @@ static gboolean _program_f_gtk_tree_sele
 	return program_f (self, selection, model, path, path_currently_selected);
 }
 
 
 void program_run (Program* self) {
 	GtkTreeView* treeview;
 	g_return_if_fail (self != NULL);
 	treeview = g_object_ref_sink ((GtkTreeView*) gtk_tree_view_new ());
-	gtk_tree_selection_set_select_function (gtk_tree_view_get_selection (treeview), _program_f_gtk_tree_selection_func, self, NULL);
+	gtk_tree_selection_set_select_function (gtk_tree_view_get_selection (treeview), (GtkTreeSelectionFunc) _program_f_gtk_tree_selection_func, self, NULL);
 	(treeview == NULL) ? NULL : (treeview = (g_object_unref (treeview), NULL));
 }
 
 
 void program_main (char** args, int args_length1) {
 	Program* _tmp0_;
 	_tmp0_ = NULL;
 	program_run (_tmp0_ = program_new ());
Comment 1 Martin Olsson 2009-08-30 15:16:25 UTC
Actually casting it in Vala is a horrible idea and not a valid workaround.

When I look carefully at the code I can see that without the cast in Vala a special function is emitted that does proper conversion:

#line 142 "pagepeople.vala"
static gboolean _page_people_on_row_select_gtk_tree_selection_func (GtkTreeSelection* selection, GtkTreeModel* model, const GtkTreePath* path, gboolean path_currently_selected, gpointer self) {
#line 154 "pagepeople.c"
	return page_people_on_row_select (self, selection, model, path, path_currently_selected);
}

... this function makes sure that you can pass a instance method (with it's impliciy "self" parameter) as a glib function pointer.

When I add the cast, what happens is that the Vala instance method (where the first param is "self") gets brutally treated like if it was actually a GtkTreeSelectionFunc. This means that the self pointer for the Program class will be set to the value of the TreeSelection selection etc. It gets really messy.


So basically, I think the only sane thing here is if Vala actually emits a proper GtkTreeSelectionFunc cast whenever this is the right thing to do.
Comment 2 Rico Tzschichholz 2018-05-17 06:31:10 UTC
No warning anymore. So closing this bug.