summaryrefslogtreecommitdiff
path: root/lisp/emacs-lisp/let-alist.el
diff options
context:
space:
mode:
authorPaul Eggert <eggert@cs.ucla.edu>2015-11-13 09:28:53 -0800
committerPaul Eggert <eggert@cs.ucla.edu>2015-11-13 09:30:00 -0800
commit4c4b520520cf6b99ce7128331a4e108e58095705 (patch)
treef61c9a61cdca1f8550bbb72aec9c703a9c449585 /lisp/emacs-lisp/let-alist.el
parent4f0ce9c8ef2c5ec1b9cf5bd1af9f54aa6fc335d0 (diff)
downloademacs-4c4b520520cf6b99ce7128331a4e108e58095705.tar.gz
emacs-4c4b520520cf6b99ce7128331a4e108e58095705.tar.bz2
emacs-4c4b520520cf6b99ce7128331a4e108e58095705.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.
Diffstat (limited to 'lisp/emacs-lisp/let-alist.el')
0 files changed, 0 insertions, 0 deletions