lua-users home
lua-l archive

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

> > That seems to work. The original test finishes normally with it. When I
> > tried to insert more than 0x7ffffff values, the process quickly allocated
> > so much memory that the OS started to page very busily, so after 10-15
> > minutes of waiting I interrupted that. I then tried to use the # operator,
> > which gave me a negative number: -2147483615. Then I scanned the table in a
> > loop looking for the max key value, and I found it was 2147483681. This is
> > the unsigned 32-bit interpretation of the same binary value. Given this, I
> > suspect that # uses a signed 32-bit integer internally, so if I had much
> > more RAM, I would probably make that overflow even more, into a small
> > positive number.
> The problem seems to be simply the return types of 'luaH_getn' and
> 'unbound_search'. (Again, I have no way to test it.) Both operate
> internally with unsigned integers, but are returning signed integers.

It is not that simple. There are some other problems in 'unbound_search'
(such as an explicit limit for keys larger than ints).

-- Roberto