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

On 09.01.2010, at 16:19, Mike Pall wrote:

And funny enough, Lua 5.2 on x86 has the exact same behavior you
complain about! :-)

??? Where are you looking at? Have you actually gave it a try?

Of course I did (you don't read my postings very often, do you?):

$ lua-5.2.0-work1 -e 'print(bit.bor(1.4, 0))'
1
$ lua-5.2.0-work1 -e 'print(bit.bor(1.6, 0))'
2

Exactly what you complained about. Still funny. :-)

I see, I certainly have not build for an SSE-less x86 CPU in some time. My build with GCC defaults did not yield it and given the SSE #ifdef I now see why.

I see it truncating by casting. It uses lua_tonumber, so it
truncates I tested before my mail on x86-64, and now double
checked with i386.

Oh, my. READ THE SOURCE and CHECK YOUR FACTS before you go on a
pointless rant. See luaconf.h:

#if defined(LUA_NUMBER_DOUBLE) && ... defined(__i386__) ...
...

not to forget && !defined(__SSE2__)

union luai_Cast { double l_d; long l_l; };
#define lua_number2int(i,d) \
{ volatile union luai_Cast u; u.l_d = (d) + 6755399441055744.0; (i) = u.l_l; }
...
#define lua_number2uint(i,n) lua_number2int(i, n)
...

Oops, Lua 5.2 does that "strange game that is the fiddling with
the union" to use your words. Oh my god -- even Lua 5.1 uses it!
Damn, checking your facts might have made SOME sense, no?

Ok, I did not remember it being there, too.

No. But given that Lua (reasonably) defaults to double I expect
to be able to use them reasonably. And not to trap into a
surprising result in every line:

-- your bitlib
= bit.band(0xffff / 256, 0xff)
0

-- lua-5.2(work1)
= bit.band(0xffff / 256, 0xff)
255

I get this:

$ lua-5.2.0-work1 -e 'print(bit.band(0xffff / 256, 0xff))'
0

Congratulations! You've just proved how platform-dependent the bit
library in Lua 5.2 really is. And how 'unreasonable' your imagined
use case really is. UNDEFINED means UNDEFINED in Lua 5.2, too!

If you object to lengthy function names, use shortcuts. Actually
band(shr(0xffff, 8), 0xff) is two characters less to type. And in
this case even shr(0xffff, 8) would suffice.

I certainly know the equivalence to shift it 8 bits to the right. My point was about undefined behavior and unexpected results.

Oh, I care about even more, I forgot ARM. Anyway, this was just
a hint that I test and work with more than the usual i386. I
could also care less about the semantics you artificially
define. I care about readable code and stuff working in ways of
the least surprise.

Well, why doesn't that much self-display of ignorance surprise me?

You're arguing for the sake of arguing. You have ZERO arguments,
absolutely NO CLUE and still keep on going. I appoint you the
honorable title "total moron of the month".