<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">Am 17.11.2013 11:58, schrieb Uli Schlachter: </div> <blockquote cite="mid:5288A16D.7050300@znc.in" type="cite"> <pre wrap="">On 16.11.2013 22:37, Jonas Petersen wrote: </pre> <blockquote type="cite"> <pre wrap="">+ /* Set bit 8 of 'request' when a 32-bit wrap has just happened + * so the sequence stays correct relatively to 'last_flushed'. */ </pre> </blockquote> <pre wrap=""> "1 << 32" does not set bit 8 and this doesn't set anything in request, really.</pre> </blockquote> You're right, sorry, "bit 8" is a typo, it's bit 32 of course. Other than that it will indeed set something. Not exactly "in request", but it will end up in unwrapped_request. <blockquote cite="mid:5288A16D.7050300@znc.in" type="cite"> <blockquote type="cite"> <pre wrap="">+ unwrapped_request = ((uint64_t)(dpy->request < dpy->xcb->last_flushed) << 32) + dpy->request; </pre> </blockquote> <pre wrap=""> Also, I don't think that this code is intuitive this way.</pre> </blockquote> I agree somewhat on that. I thought efficiency would have precedence here. I was actually inspired by <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> static void widen() in xcb_io.c where it reads: *wide = new + ((unsigned long) (new < *wide) << 16 << 16); The comment says "Treating the comparison as a 1 and shifting it avoids a conditional branch". <blockquote cite="mid:5288A16D.7050300@znc.in" type="cite"> <pre wrap="">I would propose this instead: unwrapped_request = dpy->request; /* If there was a sequence number wrap since our last flush, make sure we * use the correct 64 bit sequence number */ if (sizeof(uint64_t) > sizeof(unsigned long) && dpy->request < dpy->xcb_last_flushed) unwrapped_request += UINT64_C(1) << 32; (I am not sure/convinced if the sizeof comparision is necessary, but I saw something like this in require_socket() and then thought that this might be necessary on systems where unsigned long already is a 64 bit type.)</pre> </blockquote> I admit I haven't tought it all through on other system configurations. So thanks for giving your input. I guess the sizeof comparison would not be necessary since the condition should never meet with 64-bit longs. And if it does, something is wrong anyway (from my understanding). After all this is the trigger of the bug. Btw. as you might have guessed, on my system unsigned longs are 32-bit. - Jonas </body> </html>