Re: [ANN] Lua 5.2.0 (work1) now available

[Leo Razoumov <slonik.az@...>]

On 2010-01-18, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> > > You do not present any arguments. Actual use cases show that there
>  > > is a need. Existing bit libraries offer this functionality for
>  > > that reason, too.
>  >
>  > I agree with you on this. Arithmetic right shift is a primitive
>  > operation and I couldn't live without it.
>
>
> Just a remind: at least we would be in good company, as ANSI C does not
>  offer this operation too :)
>
>   ISO/IEC 9899:1999 (E)
>   6.5.7
>   The result of E1 >> E2 is E1 right-shifted E2 bit positions.  If E1
>   has an unsigned type or if E1 has a signed type and a nonnegative
>   value, the value of the result is the integral part of the quotient of
>   E1 / 2E2.  If E1 has a signed type and a negative value, the resulting
>   value is implementation-defined.
>
>
>  -- Roberto
>

I think there is a good reason ANSI C does not mess up with right
shifting of *negative* values. In two's complement system being
negative is a matter of interpretation. 0xFFFFFFFF and -1 have the
same bit-pattern just two different interpretations. Actually, it is
easier to restrict all bit operations to *unsigned* types so that
issues of "sign extension" never come up. In this case, the functions
that take results of bit operations as their arguments should be
properly declared as
foo(unsigned int n) instead of foo(int n). Taking FP apart can also be
done treating bit patterns as unsigned.

Bits were all born equal and at birth they all were unsigned:-)

--Leo--