|
From: | Rupert Swarbrick |
Subject: | bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame |
Date: | Wed, 1 Oct 2014 13:19:17 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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@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
[Prev in Thread] | Current Thread | [Next in Thread] |