<p dir="ltr"><br>
On Jun 6, 2013 1:37 AM, "Pekka Paalanen" <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
><br>
> On Wed,  5 Jun 2013 16:39:50 -0500<br>
> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
><br>
> > In order to use the second-lowest bit of each pointer in wl_map for the<br>
> > WL_MAP_ENTRY_LEGACY flag, every pointer has to be a multiple of 4.  This<br>
> > was a good assumption, except with WL_ZOMBIE_OBJECT.  This commit creates<br>
> > an actual static variable to which WL_ZOMBIE_OBJECT now points.  Since<br>
> > things are only every compared to WL_ZOMBIE_OBJECT with "==" or "!=", the<br>
> > only thing that matters is that it is unique.<br>
> ><br>
> > Signed-off-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br>
> > ---<br>
> >  src/wayland-private.h | 5 +++--<br>
> >  src/wayland-util.c    | 2 ++<br>
> >  2 files changed, 5 insertions(+), 2 deletions(-)<br>
> ><br>
> > diff --git a/src/wayland-private.h b/src/wayland-private.h<br>
> > index a648538..6f7a347 100644<br>
> > --- a/src/wayland-private.h<br>
> > +++ b/src/wayland-private.h<br>
> > @@ -34,13 +34,14 @@<br>
> >       const __typeof__( ((type *)0)->member ) *__mptr = (ptr);        \<br>
> >       (type *)( (char *)__mptr - offsetof(type,member) );})<br>
> ><br>
> > -#define WL_ZOMBIE_OBJECT ((void *) 2)<br>
> > -<br>
> >  #define WL_MAP_SERVER_SIDE 0<br>
> >  #define WL_MAP_CLIENT_SIDE 1<br>
> >  #define WL_SERVER_ID_START 0xff000000<br>
> >  #define WL_CLOSURE_MAX_ARGS 20<br>
> ><br>
> > +extern struct wl_object global_zombie_object;<br>
> > +#define WL_ZOMBIE_OBJECT ((void*)&global_zombie_object)<br>
> > +<br>
> >  /* Flags for wl_map_insert_new and wl_map_insert_at.  Flags can be queried with<br>
> >   * wl_map_lookup_flags.  The current implementation has room for 1 bit worth of<br>
> >   * flags.  If more flags are ever added, the implementation of wl_map will have<br>
> > diff --git a/src/wayland-util.c b/src/wayland-util.c<br>
> > index 162b352..7a0b268 100644<br>
> > --- a/src/wayland-util.c<br>
> > +++ b/src/wayland-util.c<br>
> > @@ -29,6 +29,8 @@<br>
> >  #include "wayland-util.h"<br>
> >  #include "wayland-private.h"<br>
> ><br>
> > +struct wl_object global_zombie_object;<br>
> > +<br>
> >  WL_EXPORT void<br>
> >  wl_list_init(struct wl_list *list)<br>
> >  {<br>
><br>
> So, global_zombie_object gets compiled into wayland-util.o, which makes<br>
> it private/hidden in both libwayland-server.so and<br>
> libwayland-client.so. Is there any danger of these getting mixed up,<br>
> when a program links to both?<br>
><br>
> The identity of the zombie depends on which library's util functions<br>
> actually get called, right? Looking at wayland-util.h, there are no<br>
> public entry points that would both be shared and access a wl_map. Only<br>
> functions unique to either libwayland-server or libwayland-client will<br>
> access a wl_map, so I assume they would be linked to the wayland-util.o<br>
> symbols in that specific library. Default visibility = hidden should<br>
> guarantee that.<br>
><br>
> Am I right that there is no danger here?</p>
<p dir="ltr">Even better, server side should never use zombie objects at all.  However, it is used in connection.c, so I had to put it in wayland-util.  This is one of those places where the "shared code" between client and server isn't quite as generic/universal as one would like.</p>

<p dir="ltr">Thanks for reviewing,</p>
<p dir="ltr">--Jason Ekstrand</p>