GNOME Bugzilla – Bug 651793
gobject warnings from g_atomic_pointer_compare_and_exchange
Last modified: 2011-06-03 19:19:07 UTC
$ grep warn /tmp/build-glib.log gparam.c:251:44: warning: dereferencing type-punned pointer will break strict-aliasing rules gparam.c:251:11: warning: dereferencing type-punned pointer will break strict-aliasing rules gobject.c:2387:48: warning: dereferencing type-punned pointer will break strict-aliasing rules gobject.c:2387:15: warning: dereferencing type-punned pointer will break strict-aliasing rules gobject.c:2393:48: warning: dereferencing type-punned pointer will break strict-aliasing rules gobject.c:2393:15: warning: dereferencing type-punned pointer will break strict-aliasing rules It looks to me like the macro takes void ** as its first argument, while the function takes void*.
<walters> mclasen, desrt: what is the purpose of (void) (0 ? (gpointer) *(atomic) : 0); in g_atomic_pointer_compare_and_exchange ? isn't that dead code? <walters> or am i missing something obvious? gcc 4.5 here warns about this (i think it's this): gparam.c:251:44: warning: dereferencing type-punned pointer will break strict-aliasing rules <mclasen> walters: yes, dead code that triggers type checks at compile time <mclasen> thats exactly the intention it causes the compiler to tell you that your code has a problem <walters> well this is code in gobject which is in the same module as glib so i'd sort of expect we fix it when gatomic.h is changed =) hm, is gparam.c buggy? looking note this isn't the G_STATIC_ASSERT which makes total sense to me <mclasen> walters: desrt explained that extra magic to me at some point, but I forgot <mclasen> walters: we should take out the explicit casts in gparam.c <walters> in this case the macro and function seem inconsistent the function takes volatile void * the macro wants void ** which are quite different things <mclasen> no the function takes a gpointer * not a gpointer <walters> gboolean g_atomic_pointer_compare_and_exchange (volatile void *atomic, gpointer oldval, gpointer newval); <walters> well we should probably do this in a bug so 5 years later i can search for it it's not urgent, i just like my metabuild output to be clean so i know i'm not regressing anything <mclasen> oh, I was looking at old headers anyway, I believe what the macro is trying to ensure is that the thing pointed to by atomic is a pointer <walters> https://bugzilla.gnome.org/show_bug.cgi?id=651793 <bugbot> Bug 651793: glib, normal, Normal, ---, gtkdev, UNCONFIRMED, gobject warnings from g_atomic_pointer_compare_and_exchange <mclasen> and while the function declaration does not say so, it certainly expects to be given a pointer to a pointer
*** This bug has been marked as a duplicate of bug 651514 ***