[Xcb] [PATCH] util-cursor: Fix minor memleak and fix the RENDER version check

[Josh Triplett]

On Fri, Sep 20, 2013 at 11:11:23AM -0700, Jamey Sharp wrote:
> On Thu, Sep 19, 2013 at 11:37:30AM -0700, Josh Triplett wrote:
> > On Thu, Sep 19, 2013 at 08:10:51PM +0200, Uli Schlachter wrote:
> > > On 19.09.2013 19:31, Josh Triplett wrote:
> > > Uhm, should I turn the attached diff into a proper commit? :-P
> > 
> > > diff --git a/src/xcb_conn.c b/src/xcb_conn.c
> > > index fd9b4d8..dff96c6 100644
> > > --- a/src/xcb_conn.c
> > > +++ b/src/xcb_conn.c
> > > @@ -308,7 +308,7 @@ xcb_connection_t *xcb_connect_to_fd(int fd, xcb_auth_info_t *auth_info)
> > >  
> > >  void xcb_disconnect(xcb_connection_t *c)
> > >  {
> > > -    if(c->has_error)
> > > +    if(!c || c->has_error)
> > >          return;
> > >  
> > >      free(c->setup);
> > 
> > Given that xcb_disconnect frees the connection: yes, please do, and
> > update the documentation accordingly to say that NULL is acceptable.
> 
> This is a harmless enough proposal, so I won't fight it, beyond pointing
> out that XCB never returns a null connection--even on memory allocation
> failure. Having something in XCB handle a case that XCB never generates
> seems odd to me.

Not that odd.  You might have a pile of things including an
xcb_connection_t *, and this allows you to have a simple exit path that
just unconditionally calls xcb_disconnect, without having to know if
xcb_connect has been called yet.

(On that note, this change also needs to bump the minor version of
libxcb in libtool, such that code compiled against this version won't
run against earlier versions.)

- Josh Triplett