lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 27 April 2012 21:48, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>> When using the ieee754 trick on an x86_64 machine where
>> sizeof(lua_Integer) ==8 and sizeof(int) == 4, the following fails in
>> 5.2 yet passes in 5.1
>>
>>               CPPUNIT_ASSERT(sizeof(lua_Integer) == 8);
>>               CPPUNIT_ASSERT(sizeof(int) == 4);
>>               lua_Integer input = 0x1ffffffff;
>>               lua_pushinteger(l, input );
>>               CPPUNIT_ASSERT_EQUAL(input,lua_tointeger(l,1));
>>
>>
>> This is due to lua_number2integer when LUA_IEEE754TRICK is defined and
>> called by lua_tointegerx
>> #define lua_number2integer(i,n)               lua_number2int32(i, n, lua_Integer)
>
> So, this is a bug, but I do not know what would be the best fix: to
> change lua_number2integer to work correctly for 8 bytes or to change
> lua_Integer to be a 4-byte integer.
>
> -- Roberto
>

Ouch, did not expect that.

Personally, at best I would like full support for 8 byte ints as
"well, 64 bit machines are becoming a commodity now (a German grocery
store is selling them over the counter ;-))" although I am sure this
is not on the cards. More realistically I would like lua_Integer to
stay an 8 byte type on the machines where ptrdiff_t is and therefore
partially support eight byte ints as did 5.1[2], with the possibility
of adjusting Lua to fully support it per a user's config[3].


[1] http://lua-users.org/lists/lua-l/2004-11/msg00032.html
[2] http://code.google.com/p/oolua/source/browse/branches/user_data/unit_tests/tests_may_fail/push_pull_may_fail.cpp
[3] http://lua-users.org/lists/lua-l/2010-11/msg00098.html

Liam