Re: bitpack.c odditiy

Timothy B. Terriberry wrote:
> Nils Pipenbrinck <[email protected]> wrote:
>
>   
>> While browsing the code I came across line 83 bitpack.c:
>>
>>   *_ret=((ret&0xFFFFFFFFUL)>>(m>>1))>>(m+1>>1);
>>
>> Is there any reason why this is so convoluted? Maybe endianess or 64 bit
>> issues? If I'm not mistaken it does exactly the the same as:
>>
>>   *_ret = ret >> m;
>>     
>
> Yes, there is. 64-bit issues, as you noted, require the mask. It  
> should be optimized out by a 32-bit compiler. However, m can take the  
> full range of values from 0 to 32. 

Ah! It shifts by 32 as well. Now it all makes sense and it's very clever 
as well.

Thanks for the explanation.

Cheers,
  Nils