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

Javier Celaya javier.celaya at flexvdi.com
Wed Aug 22 07:03:03 UTC 2018


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 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20180822/e777f655/attachment-0001.html>


More information about the Spice-devel mailing list