RE: small gotcha with cdata and number
- From: William Adams <william_a_adams@xxxxxxx>
- To: <luajit@xxxxxxxxxxxxx>
- Date: Wed, 30 May 2012 18:18:34 +0000
Yah, I actually use bit.tobit, but, before I did that,
the part that actually was biting me was this:
avar = 0x100000000ULL
This creates a value of cdata type, rather than number.
Ignoring this specific usage, should this hex literal
be converted to a number or cdata? I'd assume number.
This is with beta9, and possibly it's been fixed?
-- William
===============================
- Shaping clay is easier than digging it out of the ground.
http://williamaadams.wordpress.com
http://www.thingiverse.com/WilliamAAdams
https://github.com/Wiladams
----------------------------------------
> Date: Wed, 30 May 2012 19:57:04 +0200
> From: mike-1205@xxxxxxxxxx
> To: luajit@xxxxxxxxxxxxx
> Subject: Re: small gotcha with cdata and number
>
> William Adams wrote:
> > As part of a SHA1 calculation, there is this function
> >
> > which will add two 32-bit numbers, and ensure the
> >
> > result is still 32 bits.
> >
> > -- adding 2 32bit numbers, cutting off the remainder on 33rd bit
> > local function w32_add (a,b)
> > return (a+b) % 4294967296
> > end
>
> Ick, please don't do that -- it's very slow.
>
> Use bit.tobit(a+b) explicitly, if you must. But you can avoid that
> in most cases, since you're passing these things to other bit.*
> functions, which implicitly perform the bit.tobit() conversion.
>
> In fact, the JIT compiler optimizes a+b passed to a bit operation
> into a simple 32 bit integer ADD in the machine code.
>
> The Lua BitOp distribution has an example MD5 implementation that
> generates pretty good code with LuaJIT 2.0: http://bitop.luajit.org
>
> --Mike
>
Other related posts:
