Re: Bitshifting negatives in Pike is a little sketchy

I have backported the commit in pike 8 to pike 7.8, which fixed this issue.

On 10/21/16 11:40, Arne Goedeke wrote:
> Hi Douglas,
> 
> this is indeed a bug in 7.8 (which has already been fixed in pike 8).
> This is caused by an overflow check in the operator. The reason is that
> in C a right shift by a negative number is implementation defined. I
> suppose there are no relevant implementations which don't do an
> arithmetic right shift, so the check can be made less strict.
> Thanks for the report, will fix.
> 
> Arne
> 
> On 10/21/16 10:46, Douglas Gardner wrote:
>> Hi all,
>>
>> In Pike 7.8, the following operations happen:
>>
>> 25 >> 1 → 12
>> -25 >> 1 → -1
>> 25 >> -1 → Bad argument 2 to >>(). Expected int(0..)|object.
>> -25 >> -1 → Bad argument 2 to >>(). Expected int(0..)|object.
>>
>> Only the first one of these is handled correctly.
>> Bitshifting negative integers is a generally sketchy business in many
>> languages, but most seem to agree that -25 >> 1 is -13. However, in
>> Pike, right bitshifting any negative integer results in -1 (which is
>> rather wrong!).
>>
>> 25 >> -1 and -25 >> -1 are a little undecided. In most languages, such
>> as Python, Java and Perl, they return 0. In C and Ruby, a negative
>> right shift turns into a left shift, so they return 50 and -50.
>> In Python and Go, they raise errors. All three approaches are valid,
>> but in Pike we hit a fairly opaque unknown program error -- this
>> should change to match the behaviour of <<(), which is to tell you off
>> about a negative shift count.
>>
>>
>> All in all, we should:
>> * make a negative shifted by a positive work correctly
>> * make a negative shifted by a negative either work sensibly, or tell
>> you off properly
>>
>> Thanks,
>> Douglas
>>
>>
>