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

[Jan Djärv]

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.