Re: type-punning warnings with optimizations turned on?

["Alan M. Evans" <gtkappdevellist alanevans org>]

On Fri, 2007-07-06 at 08:22 -0700, wallace owen l-3com com wrote:
> On Fri, 2007-07-06 at 08:00 -0700, Alan M. Evans wrote:
> > On Fri, 2007-07-06 at 09:27 +0200, Jonathan Winterflood wrote:
> > > Wouldn't that be
> > > typedef struct MyMutex MyMutex;
> > > rather?
> > > 
> > > Or for short :
> > > typedex struct _MyMutex {
> > >     GStaticMutex mutex;
> > > } MyMutex;
> > 
> > Hi. Thanks for the input. But since this is C++, I'm not sure how that
> > makes a difference. Anyway, I tried it and the warnings remain.
> 
> That's right, your
> 
>     struct MyMutex {
>         GStaticMutex mutex;
>     };
> 
> is correct in C++.  You forgot to mention that you were using C++.  It
> makes a difference here.

Well, I did provide my compile line, which used g++ rather than gcc.

I'm not sure I've ever even seen the type-punning warnings in any of my
C code. Could be wrong about that, I guess.

> You say accessing GStaticMutex thingies elsewhere in your program
> doesn't elicit these warnings?
> 
> Check to see if all the other places where you use it are places where
> the thing being used is actually a pointer to a GStaticMutex.

A quick grep tells me that it always a fully-qualified member, always
passed to _init(), _lock(), and _unlock() with &. In short, they look
basically like this one.

Hmmm. Now that I'm recompiling everything by hand, I see that this
warning is everywhere I call g_static_mutex_lock() and
g_static_mutex_unlock(). I just did:

        void test() {
            static GStaticMutex mutex;
            g_static_mutex_init(&mutex);
            g_static_mutex_lock(&mutex);
            g_static_mutex_unlock(&mutex);
            g_static_mutex_free(&mutex);
        }

And that produces warnings on the lock and unlock calls. Same with the
example from the online API docs, which basically differs only in the
way mutex is initialized.

> I searched for GStaticMutex in /usr/include/glib2.0/*/*.h and found no
> definition or declaration for it.  Therefore you can't hold one in your
> program: they are opaque objects.  You must only hold pointers to them.
> 
> You can also initialize them statically via a macro.  This is the text
> of a comment in gthread.h (the only .h file in the glib2.0 header tree):
> 
> /* GStaticMutexes can be statically initialized with the value
>  * G_STATIC_MUTEX_INIT, and then they can directly be used, that is
>  * much easier, than having to explicitly allocate the mutex before
>  * use
>  */

The API docs state explicitly that GStaticMutex is *not* opaque. In
fact, G_STATIC_MUTEX_INIT would be worthless if we could only hold a
pointer to GStaticMutex. And g_static_mutex_init() requires a pointer to
an already existing GStaticMutex. There's no g_static_mutex_new() like
there is a g_mutex_new().

Anyway, if GStaticMutex were opaque then the g_new() call in my code
wouldn't compile, I think.

Thanks for weighing in. It's beginning to look like I might just need to
live with the worthless warning...