[Spice-devel] [PATCH] Avoid passing libusb functions as callbacks

[Victor Toso]

Hi,

On Wed, Aug 22, 2018 at 09:03:03AM +0200, Javier Celaya wrote:
> Hi,
> El mar, 21-08-2018 a las 09:47 -0400, Frediano Ziglio escribió:
> > 
> > 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 thecode
> > Are 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 opened the bug report:https://gitlab.gnome.org/GNOME/glib/issues/1494

I've added this to commit log and pushed.
https://gitlab.freedesktop.org/spice/spice-gtk/commit/558c967ecd230fa6dd

Thanks again,
Victor

> > 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,Victor
> > 
> > In 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
>       
>       
>         
>            
>         javier.celaya at flexvdi.com
>         
>         
>           
>         +34696969959 
>       
>           
>         j_celaya
>         
>         
>           
>         Legal Information and Privacy Policy
>           
>       
>     
>     
>         
>             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 at flexvdi.com. 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). 
>         
>     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20180822/c1504b77/attachment.sig>