Re: Bit library in Lua 5.2

[Doug Rogers <doug.rogers@...>]

duck wrote:
> I _almost_ wrote off Mike Pall's arguments on the basis of tone and style 
> alone. (Mike, they were so gruesomely flamesome...

Wow. I've just caught up with the amazing events of the weekend. Though
I can understand his pain, I expected more from him.

> Also, since I expect one common usage of the bit operations to be 
> crypto-related, I'd like to see standard library functions to return a 
> 32-bit style number as a 4-character string, in either endianness., e.g.
>  bit.tou32le(number)
> ... The reason for this esoteric-sounding function is that XORing
> strings together is one of the most fundamental "final steps" in
> a stream cipher, ...

I wrote two libraries that operate on bit strings. The first, bstring,
actually handles all the bit strings for you and includes a lot of
manipulation functions (bitwise operators, Golay encoding, CRCs, etc.).
Bstrings may be thought of as an ordered list of ones and zeros. The bit
indexes start at 1, like in Lua strings. Later I became unhappy with
that decision, but it does allow me to think of bstrings as if they are
Lua strings of '0' and '1' characters.

The second, strbit, is a simple library that allows bitwise operations
on Lua strings. You might be interested in it. I wrote it because it is
less intrusive and does not create its own type (udata). In all cases,
if one string is shorter than the other, the result is the length of the
longer, assuming the shorter to be padded by zeros. Bit indexes start at
0 and negative bit indexes are allowed to refer to the end of the
string. This is more natural for bit operations.

strbit.band(s1,s2)      -- bitwise AND of bytes in s1, s2
strbit.bor(s1,s2)       -- bitwise OR of bytes in s1, s2
strbit.bxor(s1,s2)      -- bitwise XOR of bytes in s1, s2
strbit.bsub(s,i1[,i2])  -- like string.sub, but with bit indexes
strbit.bword(s,i1[,i2]) -- extract bits as a number, LSB first
strbit.install()        -- put functions into string table

I would need to add a strbit.bstr() to convert a number into a string
(the opposite of bword()) in order to satisfy your need for
bit.tou32le(number).

If you're interested, I'll send or post a copy. Here are some excerpts
from my unit test:

require'strbit'
function xc(xx) return string.char(tonumber(xx, 16)) end
function X(s) return (s:gsub("(%x%x)", xc)) end
function WX(n) return string.format('0x%X', n) end
a = "AU-"  -- 41 55 2D (00)
b = "bsKe" -- 62 73 4B  65
assert(strbit.install() == string)
expectx(X'BEAAD2'  , a:bnot())
expectx(X'40510900', a:band(b))
expectx(X'63776F65', a:bor(b))
expectx(X'23266665', a:bxor(b))
expectx(X'36B75400', b:bsub(4,-4))
expectx(X'01', b:bsub(1,1))
expect(WX(0x654B7362), WX(b:bword()))     -- default is 32 bits
expect(WX(0x004B7362), WX(b:bword(0,-9)))
expect(WX(0x000001B1), WX(b:bword(1,10)))

> Ideally, I'd like to see Lua have offical support for a range of default 
> number types -- 32-bit, double, 128-bit, etc., definitely including one 
> which gives sufficient integer range to be closed under 64-bit addition.

My preference leans towards a separate integer type. I think an integer
type would solve a lot of real application problems, but I also know it
would open Lua to other complexities.

Doug


______________________________________________________________________________________
The information contained in this email transmission may contain proprietary and business 
sensitive information.  If you are not the intended recipient, you are hereby notified that 
any review, dissemination, distribution or duplication of this communication is strictly 
prohibited.  Unauthorized interception of this e-mail is a violation of law.  If you are not 
the intended recipient, please contact the sender by reply email and immediately destroy all 
copies of the original message.

Any technical data and/or information provided with or in this email may be subject to U.S. 
export controls law.  Export, diversion or disclosure contrary to U.S. law is prohibited.  
Such technical data or information is not to be exported from the U.S. or given to any foreign
person in the U.S. without prior written authorization of Elbit Systems of America and the 
appropriate U.S. Government agency.