GNU bug report logs -
#18586
24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame
Previous Next
Reported by: Rupert Swarbrick <ruperts <at> broadcom.com>
Date: Mon, 29 Sep 2014 20:36:04 UTC
Severity: normal
Found in version 24.4.50
Done: Rupert Swarbrick <ruperts <at> broadcom.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
I've done some more investigating and I think I know what's wrong.
In x_ewmh_activate_frame (in xterm.c), we cons up a list containing 1 and
dpyinfo->last_user_time. The latter number is a "Time", which is declared in
X.h. The type will be at least 32 bits wide and it gets filled with an unsigned
32 bit number.
In x_fill_property_data in xselect.c, this number gets checked against
X_LONG_MIN and X_LONG_MAX, which are the limits of a signed 32 bit number. This
is incorrect, I think.
In my original bug report, I'd gone to the effort of bisecting and finding the
patch that triggers this bug. I'd forgotten that a git sha hash is less than
helpful though, so I'll be more explicit:
* This bug is triggered by an incorrect patch that was committed on 7/9/2014.
* The subject line for the commit is
"Adjust drag-and-drop fix when window is above top."
* The changelog message is:
+2014-09-07 Paul Eggert <eggert <at> cs.ucla.edu>
+
+ Adjust drag-and-drop fix when window is above top (Bug#18303).
+ * xselect.c (x_fill_property_data): Don't let sign bit of negative
+ XCDR bleed into XCAR's encoded value. Improve checks for
+ out-of-range data while we're at it.
+
I think that this shows that the "improved" checks are incorrect and, with the
API in xselect.c, you can only check that the 64-bit sign extended value is
between X_LONG_MIN and X_ULONG_MAX.
Rupert
This bug report was last modified 10 years and 288 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.