bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Rupert Swarbrick <ruperts@broadcom.com>]

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