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

Martin Gräßlin mgraesslin at kde.org
Tue Feb 25 04:27:18 PST 2014


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.

Cheers
Martin Gräßlin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20140225/f0ee1248/attachment.pgp>


More information about the Xcb mailing list