GNOME Bugzilla – Bug 511229
Fix aliasing warnings from g_module_symbol()
Last modified: 2018-02-10 04:34:12 UTC
Attached patch fixes all aliasing warnings from g_module_symbol() by introducing local gpointer variables. It also touches cases where local variables were already used so all use cases of g_module_symbol() in gtk+/*/* look about the same.
Created attachment 103420 [details] [review] Patch against trunk implementing the above
Hmm, I grudgingly agree to add all those extra variables.
Created attachment 103884 [details] [review] Alternative patch I agree it is ugly to have all these temp variables. What about this alternative patch? It still warns on (gpointer *) casts, but does not warn if you omit the cast completely, as seen in two use cases in gmodule.c itself.
Still an issue? Having a patch here, set to accepted-commit_now but rotting in Bugzilla.
Rejected both patches, as I have two different approaches: a) leave the g_module_symbol() prototype as it is and convert calls to this: g_module_symbol (,, (void* __attribute__((__may_alias__)) *) &var); The cast could be embedded in some kind of G_SYMBOL_ADDRESS(ptr) macro. b) change the g_module_symbol() prototype to: gboolean g_module_symbol (GModule *module, const gchar *symbol_name, void *symbol); Just like (char*), (void*) may alias any type, so supresses gcc's type alias analysis. Both variants work for me in a test program for gcc-4.1, g++-4.1, gcc-4.2 and g++-4.2. The current prototype declaration which expects a gpointer*symbol is of questionable use anyway, since most often callers will actually want to pass a function pointer address here, so are forced to use explicit casts. Explicit casts however blinden the compiler, and since we're giving up type safety for the symbol argument anyway, we might as well do it in a way that doesn't get gcc's aliasing logic confused.
G_GNUC_MAY_ALIAS is already in glib.
(In reply to comment #6) > G_GNUC_MAY_ALIAS is already in glib. That doesn't quite help here, i.e. the cast is so complicated that i think a macro like G_SYMBOL_ADDRESS() is still needed if (a) was implemented.
Humm, does adding G_GNUC_MAY_ALIAS on the argument in the function signature help? Note that another way to turn the warning off is to cast to gpointer in the middle. That is: (gpointer*)(gpointer)something Note that at the end of the day, only adding G_GNUC_MAY_ALIAS on the function signature really turns the gcc aliasing analysis off. Any solution that only affects the call site is just turning the warning off. gcc still has made aliasing assumptions when compiling the body of the g_module_symbol() function.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.