Re: [PATCH] Avoid passing libusb functions as callbacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 fixed
inGlib, it is matter to help other projects that port code
towindows to be fixed as well, etc.
Please open a bug in Glib and add a reference to it in the
code

Are you talking to Jorge or to Frediano (since he has a fixed
macro)?

Jorge is on holidays anyway, he will return in a couple of
weeks. I can open the bug report in Glib, but if you already
have a working version of the macro...

Either way is fine. If you open a bug, Frediano can attach his
patch 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 comment
in the code about it. I don't mind patching the code with the
comment 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 basically
changing compiler you can have the bug or not.

The fix for the convention problem is to just call destroy without
converting it to GDestroyNotify (a void* should be fine in C although
in C++ won't work).

The 2 definitions are also incoherent, one is using pp once the other
twice so changing compilers you can have other side effects (note the
"Only one access, please" comment).

Frediano

-- 


flexVDI

Javier Celaya Alastrué

Chief Technology Officer

email javier.celaya@xxxxxxxxxxx

Phone +34696969959

Skype j_celaya

Legal 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@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

[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]