GNOME Bugzilla – Bug 662797
G_STATIC_MUTEX_INIT() does not initialize all fields, causing a compiler warning
Last modified: 2011-10-28 19:28:08 UTC
On Wed, 2011-10-26 at 15:12 -0400, Ryan Lortie wrote in an email: hi Murray, > > I reverted this commit for now. OK. Sorry for assuming that it would be OK. http://git.gnome.org/browse/glib/commit/?id=52fd106724aa79ad57ecaa7ad9d340f8c89da06d I didn't see you on irc at the time and didn't want to bother people with a big discussion about such a minor issue. > Can you please open a bug to discuss this? I don't think your fix is > correct since the extra field is never used anymore. Even an unused struct field should be initialized to something non-random, I feel, and the compiler's warning agrees - This was meant to fix compiler warnings such as: error: missing initializer for member ‘GStaticMutex::unused’ [-Werror=missing-field-initializers] cc1plus: all warnings being treated as errors This can happen when using -Wextra, in this case with -Werror. Like many people, I like to use warnings-as-errors, so I hunt down every single warning. Many projects associated with glibmm/gtkmm do the same, and I'll be the one that they ask when they see this. G_STATIC_MUTEX_INIT() is deprecated but still used in code. People should switch over to Mutex, but in the meantime, I see no reason to introduce a new compiler warning other than the deprecation warning. I see no disadvantage to fixing it. Do you? I made a similar fix before the struct definition was changed, after recent versions of gcc started complaining about this: http://git.gnome.org/browse/glib/commit/glib/gthread.h?id=34b7126a4e0b743b07b9d55309fce0d15802b69c http://git.gnome.org/browse/glib/commit/glib/gthread.h?id=7ba753b002ca9888a46137b65f347a2f5f408e9e (I first noticed this problem in libgda's C code.)
So these are my four issues: 1) we are never actually using this field -- it's just there to take up space in order to keep the ABI the same. 2) i'm concerned about the macro not being defined on all platforms or in all cases -- we've already been bit by missing copies of these macros with certain compiler flags. 3) anything missing from the initialiser is defined as being zero-filled 4) -Wextra -Werror seems like a good way of breaking your build -- particularly considering the fact that you're using code that is marked with deprecated attributes already (but I guess you manually disabled that warning)
(In reply to comment #1) > So these are my four issues: > > 1) we are never actually using this field -- it's just there to take up space > in order to keep the ABI the same. Yes, you said that already and I already replied to that. > 2) i'm concerned about the macro not being defined on all platforms or in all > cases -- we've already been bit by missing copies of these macros with certain > compiler flags. OK. Do you have another suggestion? > 3) anything missing from the initialiser is defined as being zero-filled I'm interested in removing the warning, not in whether this particular warning is worthwhile. > 4) -Wextra -Werror seems like a good way of breaking your build -- It's been fine for me so far in a great deal of code. And as far I know, this is the _only_ thing in all of the glib and GTK+ (and much of GNOME) headers that triggers a -Wextra waring. > particularly > considering the fact that you're using code that is marked with deprecated > attributes already That is called deprecating and breaking. Deprecation is not meant to be breaking. > (but I guess you manually disabled that warning) Yes. I don't see the point of discussing this much more. It's clearly not something that you care about even if we could deal with 2) or decide to deal with it if it's a problem. Luckily people can avoid it by avoiding the deprecated API. Thank you anyway.