summaryrefslogtreecommitdiff
path: root/lisp/emacs-lisp/generic.el
diff options
context:
space:
mode:
authorPaul Eggert <eggert@cs.ucla.edu>2015-11-13 09:28:53 -0800
committerEli Zaretskii <eliz@gnu.org>2015-11-13 22:02:13 +0200
commitda05685d0b5d0d39aa774e7b236bf4d1ed4c64f5 (patch)
treef61c9a61cdca1f8550bbb72aec9c703a9c449585 /lisp/emacs-lisp/generic.el
parent97226341ec9e5887a0222499525a30453c066905 (diff)
downloademacs-da05685d0b5d0d39aa774e7b236bf4d1ed4c64f5.tar.gz
emacs-da05685d0b5d0d39aa774e7b236bf4d1ed4c64f5.tar.bz2
emacs-da05685d0b5d0d39aa774e7b236bf4d1ed4c64f5.zip
Port recent XCB changes to 64-bit ‘long int’
For historical reasons, libX11 represents 32-bit values like Atoms as ‘long int’ even on platforms where ‘long int’ is 64 bits. XCB doesn’t do that, so adapt the recent XCB code to behave properly on 64-bit platforms. Also, fix what appears to be a bug in the interpretation of xcb_get_property_value_length, at least on my Fedora platform which is running libxcb-1.11-5.fc21. * src/xfns.c (x_real_pos_and_offsets): * src/xterm.c (get_current_wm_state): xcb_get_property_value_length returns a byte count, not a word count. For 32-bit quantities, xcb_get_property_value returns a vector of 32-bit words, not of (possibly 64-bit) long int. Backport.
Diffstat (limited to 'lisp/emacs-lisp/generic.el')
0 files changed, 0 insertions, 0 deletions