Re: Lua string library partially reimplemented in Lua

[Mike Pall <mikelu-0809@...>]

M Joonas Pihlaja wrote:
> On Fri, 19 Sep 2008, Mike Pall wrote:
> >   Input arguments to bit operations are reduced to a 32 bit integer
> >   by taking their least-significant 32 bits.
> 
> Is there some reason why this couldn't be an unsigned 32 bit
> integral number?  Granted, bitwise operations don't really care
> and I can see how an implementation using an existing signed int
> framework would be attractive, but from an application developer
> perspective I think unsigned is the less surprising
> interpretation.  Unsigned masks are after all by far more common.

Well, you can pass both numbers in the signed or unsigned 32 bit
range to all bit operations and they 'do the right thing'. Only
the two different right shifts have a concept of signedness.

Whether to write bit.band(a, 0xffff0000) or bit.band(a, -0x10000)
is the programmer's choice. Of course the former is largely
preferred, but the implementation doesn't care.

I think the only potentially confusing part may be that the output
is a signed number. One has to be careful with comparisons and
with conversions to strings (%u or %x work as expected). But other
than that, I've encountered no obvious pitfalls.

The rationale for returning signed numbers is two-fold:

- The definition for bit operations must hold for platforms where
  lua_Number is an integer, too. This must be a signed quantity of
  at least 32 bits. A definition returning unsigned numbers
  doesn't make sense on a platform where lua_Number is an int32_t.

- Conversions between signed integers and doubles are generally
  fast on all platforms that have an FPU. Conversions to and from
  unsigned integers of different sizes can be quite slow. Some
  platforms even require calling a helper function.

--Mike