[Xcb] Size of errors

Uli Schlachter psychon at znc.in
Sun May 4 09:47:42 PDT 2014


Hi Alexander,

On 04.05.2014 15:25, Alexander Mezin wrote:
> Hi there.
> I have few questions regarding xcb error handling, and can't find
> answers in documentation.
> 
> Considering the following code:
> 
> xcb_generic_error_t *e = xcb_request_check(connection, cookie);
> if (e)
>     xcb_generic_error_t v = *e;
> 
> Is it safe?

Yes.

> Do all xcb_*_error_t structs have size <= sizeof(xcb_generic_error_t) ?

Not only "<=". They all have the exact same size.

At least they should, the first other error that I found,
xcb_xfixes_bad_region_error_t, has a different size...

Packets are read from the X server in src/xcb_in.c, function read_packet(). This
function first gets 32 bytes from the FD which contains all the needed
information to figure out more.

All replies (response_type == XCB_REPLY == 1) have their length field in byte
position 4 to 7.

All GenericEvents (see the "XGE extension", response_type == XCB_XGE_EVENT ==
35) have a length field at the same position.

All other packets are just 32 bytes in length.

All the structs that XCB defines are "just" the on-wire representation of
events. However, there is one exception: Replies additionally get a
full_sequence field inserted which doesn't exist "on the wire".

> Does libxcb always allocate a buffer with size >= sizeof(xcb_generic_error_t) ?

Same function (simplified):

    bufsize = length + eventlength + nfd * sizeof(int)  +
        (genrep.response_type == XCB_REPLY ? 0 : sizeof(uint32_t));
    buf = malloc((size_t) bufsize);

Where length is initialized to 32 at the beginning of the function and only ever
increased later.

> May I rely on this behavior in future?

Sure

> Also, do the same rules apply to checked calls with return value
> (xcb_something_reply)?

Yup, see above. Same code handles these.

Cheers,
Uli

P.S.: How's progress?
-- 
<alanc> I think someone had a Xprint version of glxgears at one point,
    but benchmarking how many GL pages you can print per second
    was deemed too silly to merge


More information about the Xcb mailing list