GNOME Bugzilla – Bug 772430
Instance cast macros generated by G_DECLARE_* macros don't work with const pointers
Last modified: 2016-10-04 21:55:49 UTC
The G_DECLARE_* macros generate the instance cast macro as an inline function that takes a gpointer parameter. If the supplied parameter is gconstpointer, the compiler will warn about the const qualifier being dropped.
Known issue — duplicate of bug 745068. Passing const pointers to the various type check macros is not recommended and not something that happens in idiomatic GObject code; most accessors may very well end up not being const functions that do not modify their input — simply acquiring a temporary reference, or emitting a signal would undo that. The recommendation is: do not use const pointers with GObject instances. *** This bug has been marked as a duplicate of bug 745068 ***
> Passing const pointers to the various type check macros is not recommended > and not something that happens in idiomatic GObject code; most accessors may I believe GCompareFunc (and maybe others) should be modified to not use gconstpointers so casts to the arguments work as expected in the callback then? Also I was taught early that idiomatic gobject/c code was to use const when the function doesn't modify the actual parameters, not the other way around. Is that not the case, or did I misunderstood something?
In case it makes more clear our use case, this is the function that made us report this bug report: https://git.gnome.org/browse/nautilus/tree/src/nautilus-shell-search-provider.c?id=335eabec52e26406c339a9992c432efe28f8ac5e#n177
(In reply to Carlos Soriano from comment #2) > > Passing const pointers to the various type check macros is not recommended > > and not something that happens in idiomatic GObject code; most accessors may > > I believe GCompareFunc (and maybe others) should be modified to not use > gconstpointers so casts to the arguments work as expected in the callback > then? Not really. Sorting objects is not commonly done. In any case, you can "undo" a `const`, since this is C, on a case by case basis. Making all type checking functions take a const pointer so long after the fact (and potentially for nothing) is going to break more idiomatic code. > Also I was taught early that idiomatic gobject/c code was to use const when > the function doesn't modify the actual parameters, not the other way around. > Is that not the case, or did I misunderstood something? That is *generally* the case for Plain Old Structures, or pointers to arrays of characters. For GObject, having a: bool foo_object_is_bar (const FooObject *self); is decidedly *not* idiomatic — in the sense that nobody does it.
(In reply to Carlos Soriano from comment #3) > In case it makes more clear our use case, this is the function that made us > report this bug report: > https://git.gnome.org/browse/nautilus/tree/src/nautilus-shell-search- > provider.c?id=335eabec52e26406c339a9992c432efe28f8ac5e#n177 A simple fix would be: - hit_a = NAUTILUS_SEARCH_HIT (a); - hit_b = NAUTILUS_SEARCH_HIT (b); + hit_a = (NautilusSearchHit *) a; + hit_b = (NautilusSearchHit *) b; since you control the input of the function.