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

["Jan Djärv" <jan.h.d@swipnet.se>]

Hello.

8 sep 2014 kl. 15:10 skrev Paul Eggert <eggert@cs.ucla.edu>:

> 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.
> 

Yes, you are right.

>> 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.

Right, I missed the X_.

	Jan D.