[PATCH xquartz 04/10] randr: Silence -Wshift-negative-value warnings

[Jeremy Huddleston Sequoia]

> On Oct 19, 2015, at 08:31, Adam Jackson <ajax at nwnk.net> wrote:
> 
> On Wed, 2015-10-14 at 15:44 -0700, Jeremy Huddleston Sequoia wrote:
>>> On Oct 14, 2015, at 15:33, Alan Coopersmith  wrote:
>>> 
>>> On 10/14/15 03:13 PM, Jeremy Huddleston Sequoia wrote:
>>>> rrtransform.c:199:23: warning: shifting a negative signed value
>>>> is undefined [-Wshift-negative-value,Semantic Issue]
>>>>             rot_cos = F(-1);
>>> 
>>> 
>>>> -            rot_cos = F(-1);
>>>> +            rot_cos = F(~0u);
>>> 
>>> Is -1 guaranteed to be ~0u on all platforms?   Or just all the ones
>>> we know and care about?
>> 
>> I'm pretty certain that ~0u and -1 are the same bit patterns on all
>> platforms.  I can't think of a reason why they wouldn't be.
> 
> On a ones' complement machine, (uint8_t)-1 is 0b11111110.  On a signed-
> magnitude machine, (uint8_t)-1 is 0b10000001.  But I think you're
> significantly more likely to encounter a PDP-endian machine than a non-
> two's-complement machine at this point, and there's plenty of other
> places in xserver where we're assuming two's complement, e.g.:
> 
> fb/fb.h:#define FB_ALLONES  ((FbBits) -1)

True.  I should have been explicit that I was talking about two's complement platforms when I said "all".  I just can't imagine anyone actually trying to support anything other than two's complement.  That would be insanely crazy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20151019/3744d5bc/attachment-0001.bin>