[Xcb] [PATCH libxcb 10/7] c_client.py: don't generate _aux() request functions

Ran Benita ran234 at gmail.com
Tue Feb 25 12:05:34 PST 2014

On Tue, Feb 25, 2014 at 01:27:18PM +0100, Martin Gräßlin wrote:
> On Tuesday 25 February 2014 14:11:37 Ran Benita wrote:
> > Currently, for requests which take a parameter which needs to be
> > serialized (like some complex struct), there are two types of functions
> > generated:
> >     xbc_<request_name>{,checked,unchecked}
> >     xbc_<request_name>_aux{,checked,unchecked}
> > The difference between the aux and non-aux versions is how they handle
> > the complex argument(s):
> > 
> > - The aux version takes a type-safe instance of the struct, and
> >   internally calls the _serialize() function for this struct, which
> >   translates it to its wire representation.
> > 
> > - The non-aux version instead takes a void*, unpacks it to the struct in
> >   order to calculate the sizeof, and then sends it directly.
> > 
> > The non-aux version is not type-safe and expects the user to lay out the
> > data manually. People also don't know the aux version even exists, and
> > thus use the non-aux version incorrectly.
> > 
> > Therefore, remove the non-aux versions and drop the _aux prefix
> > entirely, and make the code-generator worry about one less obscurity on
> > the way.
> Thanks for adding me to CC.
> Can I suggest to keep the _aux prefix and just delegate to the version without 
> _aux? This would make life much easier as it takes about one to two years till 
> we can start to depend on new stuff in the libraries. We basically have to 
> wait till it is available in all the distributions which our developers use to 
> build our software. And if KWin doesn't build I get yelled at ;-) That way I 
> could start introducing the proper way again using _aux and don't worry about 
> it going away in a future version of the library.

The patch is withdrawn, so I won't get into details how to make this
work. You should use the _aux version instead. It is available
(assuredly) starting from libxcb 1.10, which was released Dec 2013, so
I guess you have to wait some time yet, unless you like those yellings :)


> Cheers
> Martin Gräßlin

More information about the Xcb mailing list