|
From: SourceForge.net <no...@so...> - 2011-04-27 19:39:46
|
Bugs item #3292605, was opened at 2011-04-25 07:17 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clx Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Spencer (dangerousben) Assigned to: Bruno Haible (haible) Summary: new-clx get-property unpacks properties incorrectly on 64bit Initial Comment: >From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).' But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64. Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine. This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-04-27 15:39 Message: at any rate, on my 64-bit linux box, the following works without the patch and breaks with it: (xlib:with-open-display (dpy) (dolist (screen (xlib:display-roots dpy)) (dolist (window (xlib:query-tree (xlib:screen-root screen))) (multiple-value-bind (data type format bytes-after) (xlib:get-property window :WM_NORMAL_HINTS) (when data (assert (eq type :WM_SIZE_HINTS)) (assert (= format 32)) (assert (= bytes-after 0)) (assert (= (length data) 18)) (print (list (xlib:wm-name window) data)) (print (xlib:wm-normal-hints window))))))) ("Firefox" (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144 4294862672 4294862752 2872256880 6587458)) *** - AREF: index 6587458 for #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST :SOUTH-WEST :SOUTH :SOUTH-EAST :STATIC) is out of range ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-04-27 12:08 Message: thanks for the patch. do you have a test case? The reason I am asking is that I am not quite sure it is quite correct. (specifically, make_uint32(unsigned long) should be UL_to_I) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355 |