Re: [ANN] LuaJIT-2.0.0-beta1

[François Perrad <francois.perrad@...>]

2009/11/1 Mike Pall <mikelu-0911@mike.de>:
> François Perrad wrote:
>> 1) numeric for with step = 0 causes infinite loop
>>     $ luajit -e 'for i = 5, 7, 0 do end'
>
> This is testing implementation-defined behavior, i.e. you'll get
> undefined results. Should 'for i=a,b,0' run upwards or downwards?
> And what about 'for i=a,b,-0'?
>
> LJ2 chooses to look at the sign bit and runs downwards it it's
> set. Lua runs upwards if 0 < step. Now, please don't ask what
> happens if step is NaN. :-)
>

Nobody writes a for loop with direct 0.
The step could be the return of a function.
So, I prefer the Lua choice which prevents a infinite loop when a
positive increment is excepted.
But 'for i = 7, 5, 0' is a infinite loop with Lua.

>> 2) losing arguments with metamethod __call
>>     m = {}
>>     setmetatable(m, {
>>         __call = function (obj, ...)
>>                      print('m.__call ' .. tostring(obj) .. ', ' ..
>> table.concat(arg, ', '))
>>                  end
>>     })
>>     m()
>>     m(1, 2) --> arguments are lost
>
> 'arg' is a Lua 5.0 feature. Not supported. Use {...}.
>
>> and some new minor issues or delta :
>> 1) getfenv(-3) gives a more general message :
>>     bad argument #1 to 'getfenv' (invalid level)
>> instead of
>>     bad argument #1 to 'getfenv' (level must be non-negative)
>> same issue with setfenv().
>
> Intentional change. The common error message is precise enough.
>
>> 2) tostring of C function
>>     $ luajit -e 'print(tostring(print))'
>>     function: fast#29
>> when lua gives :
>>     function: 0x9a5d020
>
> The exact format of of a tostring'ized object is implementation-
> defined. Giving more information (since it's there) is intentional.
>
>> 3) xpcall without error handler
>>     $ luajit -e 'print(xpcall(assert, nil))'
>>     luajit: (command line):1: bad argument #2 to 'xpcall' (function
>> expected, got nil)
>> instead of :
>>     false     error in error handling
>
> I'm testing that the error handler is a function. This is
> apparently missing in the Lua codebase and it's erroring out
> later (which is not useful). File a bug against Lua.
>

Another suspect behavior is flush() with a closed file f :
   f:flush() throws the expected error
   io.flush(f) doesn't

>> 4) table.maxn
>>     $ luajit -e 't = {3,4}; print(table.maxn(t))'
>>     1
>> instead of :
>>     2
>
> Definitely a bug. Patch attached. Thank you!
>
>> 5) deprecated table.setn
>>     $ luajit -e 'table.setn({},7)'
>>     luajit: (command line):1: attempt to call field 'setn' (a nil value)
>> instead of :
>>     lua: (command line):1: 'setn' is obsolete
>
> Intentional.
>
>> 6) math.random with extra arguments
>>     $ luajit -e 'print(math.random(1, 2, 3))'
>>     2
>> instead of :
>>     lua: (command line):1: wrong number of arguments
>
> Intentional. None of the other library functions care when more
> arguments than necessary are passed.
>

Another exception is table.insert().

I'll update my test suite.

François

> Thanks for helping with testing!
>
> --Mike
>