[Xcb] [PATCH libxcb 9/7] c_client.py: don't start xcb_parts at offset 2 for no reason

[Uli Schlachter]

On 25.02.2014 21:08, Ran Benita wrote:
> On Tue, Feb 25, 2014 at 05:34:27AM -0800, Josh Triplett wrote:
>> On Tue, Feb 25, 2014 at 02:11:36PM +0200, Ran Benita wrote:
>>> Currently the generated code looks like this:
>>>
>>>     struct iovec xcb_parts[4];
>>>     xcb_big_requests_enable_cookie_t xcb_ret;
>>>     xcb_big_requests_enable_request_t xcb_out;
>>>
>>>     xcb_parts[2].iov_base = (char *) &xcb_out;
>>>     xcb_parts[2].iov_len = sizeof(xcb_out);
>>>     xcb_parts[3].iov_base = 0;
>>>     xcb_parts[3].iov_len = -xcb_parts[2].iov_len & 3;
>>>
>>>     xcb_ret.sequence = xcb_send_request(c, XCB_REQUEST_CHECKED, xcb_parts + 2, &xcb_req);
>>>
>>> But there is no reason to allocate e.g. 4 parts and then skip the first
>>> 2. Start at 0 instead.
>>
>> Take a look at the implementation of xcb_send_request: if it needs to
>> send extra data before the request, it will use the iovec entries before
>> the passed-in pointer.  Yes, that's part of the API.  It really ought to
>> be more clearly documented.
> 
> Oh, that's easy to miss. I need to add big requests to my testings.
> Thanks for catching this, and thanks Uli for documenting it.

Not just big requests. One entry can be used by xcb_send_request() if it needs
big requests, another entry might be used in send_request() if the output buffer
is full and needs to be flushed. I would say that it's virtually impossible for
any code to hit both these cases at the same time accidentally.

I would say that the later condition is rather hard to hit on purpose without
ending up with some blatantly slow code (Anyone feels like sending NoOperation
requests of size 2^16 - something small?).

Uli
-- 
“Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold.” – Anna