bug#18303: Drag and Drop fails when Emacs window/frame is above top

[Paul Eggert]

Jan Djärv wrote:
> Thanks, but it does not look right.  We can assume v1 and v2 are 16 bit signed 
> integers (X coordinates).  In general, when data is a CONS, it must be two 16 
> bit numbers.
> So (v1 << 16) | v2 is just a way of stuffing two signed 16 bits into 32 bits.
> But when v2 is long,  (v2 & 0xffff) looses the sign bit, as the code is now.

I don't see how the expression could keep the sign bit and still work. 
Suppose v1 == 27 and v2 == -1.  Then ((v1 << 16) | v2) == -1, and we've 
lost all information about v1's value.  In contrast, ((v1 << 16) | (v2 & 
0xffff) == 1835007 == 0x1bffff, so we still can retrieve information 
about v1's value by shifting this value right by 16 bits.

> I don't know why the range X_LONG_(MIN|MAX) >> 16 is relevant here, it is way 
> too large.
> Remember, val can only be 32 bit, so X_LONG_MAX >> 16 can in it self be 48 bits.

X_LONG_MAX and X_LONG_MIN are always 32-bit values, even on platforms 
where long is 64 bits.  So the range X_LONG_MIN >> 16 .. X_LONG_MAX >> 
16 is -32768 .. 32767 which should be the correct range for X.