Hi,On Tue, Aug 21, 2018 at 02:53:59PM +0200, Javier Celaya wrote:Yes, not against merging the fix. But if we can get it fixedinGlib, it is matter to help other projects that port codetowindows to be fixed as well, etc.Please open a bug in Glib and add a reference to it in thecodeAre you talking to Jorge or to Frediano (since he has a fixedmacro)?Jorge is on holidays anyway, he will return in a couple ofweeks. I can open the bug report in Glib, but if you alreadyhave a working version of the macro...Either way is fine. If you open a bug, Frediano can attach hispatch there later on.
I just think it is important to have the bug open and a commentin the code about it. I don't mind patching the code with thecomment so we don't have to wait till Jorge is back ;)Cheers,VictorIn the meantime the macro is quite changed, it's now (master)#if defined(g_has_typeof) && GLIB_VERSION_MAX_ALLOWED >= GLIB_VERSION_2_58#define g_clear_pointer(pp, destroy) \G_STMT_START { \G_STATIC_ASSERT (sizeof *(pp) == sizeof (gpointer)); \__typeof__(*(pp)) _ptr = *(pp); \*(pp) = NULL; \if (_ptr) \(destroy) (_ptr); \} G_STMT_END#else /* __GNUC__ */#define g_clear_pointer(pp, destroy) \G_STMT_START { \G_STATIC_ASSERT (sizeof *(pp) == sizeof (gpointer)); \/* Only one access, please; work around type aliasing */ \union { char *in; gpointer *out; } _pp; \gpointer _p; \/* This assignment is needed to avoid a gcc warning */ \GDestroyNotify _destroy = (GDestroyNotify) (destroy); \\_pp.in = (char *) (pp); \_p = *_pp.out; \if (_p) \{ \*_pp.out = NULL; \_destroy (_p); \} \} G_STMT_END#endif /* __GNUC__ */so the first definition is good, calling directly destroy function,on the second definition is ignoring the calling convention so basicallychanging compiler you can have the bug or not.The fix for the convention problem is to just call destroy withoutconverting it to GDestroyNotify (a void* should be fine in C althoughin C++ won't work).The 2 definitions are also incoherent, one is using pp once the othertwice so changing compilers you can have other side effects (note the"Only one access, please" comment).Frediano
--
Javier Celaya Alastrué Chief Technology Officer |
+34696969959 j_celaya |
Política de confidencialidad Este mensaje y los ficheros anexos son confidenciales dirigiéndose exclusivamente al destinatario mencionado en el encabezamiento. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y no divulgar el contenido a terceros. Los datos personales facilitados por usted o por terceros serán tratados por FLEXIBLE SOFTWARE SOLUTIONS S.L.U. con la finalidad de gestionar y mantener los contactos y relaciones que se produzcan como consecuencia de la relación que mantiene con FLEXIBLE SOFTWARE SOLUTIONS S.L.U. Normalmente, la base jurídica que legitima este tratamiento, será su consentimiento, el interés legítimo o la necesidad para gestionar una relación contractual o similar. El plazo de conservación de sus datos vendrá determinado por la relación que mantiene con nosotros. Para más información al respecto, o para ejercer sus derechos de acceso, rectificación, supresión, oposición, limitación o portabilidad, dirija una comunicación por escrito a FLEXIBLE SOFTWARE SOLUTIONS S.L.U: Avenida de Ranillas 1D, Planta 3, Oficina 3G, Zaragoza o al correo electrónico pdo@xxxxxxxxxxx. En caso de considerar vulnerado su derecho a la protección de datos personales, podrá interponer una reclamación ante la Agencia Española de Protección de Datos (www.agpd.es). |
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel