XCB and 32- vs 64-bit 'long'

XCB and 32- vs 64-bit 'long'

[Paul Eggert]

Valgrind pointed out a bug in recent XCB-related changes, in that Xlib 
converts 32-bit quantities to 'long' but XCB does not. The distinction 
matters on platforms like x86-64 where 'long' is 64 bits. Also, on my 
platform at least, xcb_get_property_value_length returns a byte count, 
not a word count; unfortunately this does not appear to be documented 
anywhere.

I just now installed a patch that I hope fixes this:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4c4b520520cf6b99ce7128331a4e108e58095705

Ken, could you please check this patch? I am by no means an expert in 
XCB. Thanks.

While we're on the subject, I assume that the goal is to replace all 
Xlib calls with XCB calls, on platforms that have XCB. Can Emacs start 
assuming XCB, and drop the old Xlib-only code? That would simplify Emacs 
maintenance.

Re: XCB and 32- vs 64-bit 'long'

[Ken Raeburn]

> On Nov 13, 2015, at 13:05, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> Valgrind pointed out a bug in recent XCB-related changes, in that Xlib converts 32-bit quantities to 'long' but XCB does not. The distinction matters on platforms like x86-64 where 'long' is 64 bits. Also, on my platform at least, xcb_get_property_value_length returns a byte count, not a word count; unfortunately this does not appear to be documented anywhere.

Yes, I found the documentation to be rather poor in that area.  I did find a discussion in an old bug report at freedesktop.org about how it was supposed to and supposedly did return a count of values rather than of bytes.  But poking around on the net at other applications using the routine, it does appear that the byte count is what’s expected, consistent with what you’re seeing.  Thanks for catching these.

> I just now installed a patch that I hope fixes this:
> 
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4c4b520520cf6b99ce7128331a4e108e58095705
> 
> Ken, could you please check this patch? I am by no means an expert in XCB. Thanks.

It looks good to me.  And I’ve run a few tests to confirm that it’s getting the right lengths for me.  It also turns out that the two properties in question are set very rarely in my testing setup, which surprised me.  So I do want to look at that a little more closely.  I’m no expert either.

> While we're on the subject, I assume that the goal is to replace all Xlib calls with XCB calls, on platforms that have XCB. Can Emacs start assuming XCB, and drop the old Xlib-only code? That would simplify Emacs maintenance.

My immediate goal was to speed up certain Emacs activities on moderate-latency networks; my connection from home to work has about a 30ms round trip time, and the non-pipelined requests for information and the synchronization calls to check for errors really added up.  It’s still slower than I’d like — takes about a second to create a new frame remotely — but it’s better than it was.

It would certainly simplify things if we could just pick one version to support, but I don’t know if it’s reasonable to assume that all the systems we want to support have moved to XCB.

Ken