[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: bug#18303: Drag and Drop fails when Emacs window/frame is above top
Date: Mon, 08 Sep 2014 06:10:31 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]