>> Has it been considered to allow greater ranges for the array part?
> Yes. They cannot be larger than size_t, which are equal to unsigned int in most 32-bit machines. size_t, for its part, can be larger, equal, or smaller than lua_Integer.
I would say that should be whatever is smaller of lua_Integer and size_t. And, of course, it would be nice to be able to override that explicitly for some exotic situations when that is really bad.
So the above won't affect (sane) 32-bit platforms, and I doubt that (sane) 64-bit platforms will be affected much. Looking at struct Table, the sizearray field is followed by a pointer field, which are both aligned on 64-bit boundary on a typical 64-bit platform, so by making sizearray a 64-bit type, the overall size is probably not going to change at all. But, of course, I do not know enough to predict the impact on the algorithms and their implementation.
> ... if there is a demand for that.
There was a sentiment earlier in this thread, which I share, that the table size should only be limited by the available memory. While I am talking about a different issue here, the size of the array part, the very fact that I reported this bug means it is possible to run into a situation when the array part becomes larger than afforded by an int. I have not used the current dev. version of Lua, so I cannot even say that the bug is fixed for me, much less what would happen if I tried to use really large arrays, but I have grounds to believe that at least in some scenarios there might be a sharp difference in performance when a table, which is logically an array, can no longer be represented internally as an array, even if there is plenty of memory still available.
