lua-users home
lua-l archive

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


John, if you really want table.insert to have different behavior, just modify ltablib.c line 41-65. The code is quite compact and not too complex. That way, you can have the language behave the way you want. It won't even be bad for people working on your codebase, considering that your variant will be more robust that the original distribution. (assuming, of course, that you don't introduce a new bug ;))

Just do a check in case 3: for a negative insert value, or an insert value greater than the size of the array.

In fact, there's already a check for an insert value greater than the size of the array, on line 52, so you could maybe make that exit the function instead of the statement "e = pos." (which itself is actually equivalent to "break," since setting e to pos will always skip the following loop.)
Then, you could just add another one for negative values.

If you want to understand Lua's "odd" behavior, just look at the code. If you send a negative value, what happens is that all the elements in the array are moved up by one and finally the negative index is added to the array at the index specified.

i.e.:
start_table = {[1] = "a", [2] = "b", [3] = "c" }
table.insert(  start_table, "z", -10 )

start_table now equals { [-10] = "z", [2] = "a", [3] = "b", [4] = "c" }.

This is because the code is basically assuming that an insert value less than the insert must be greater than or equal to 1, and that everything to its "right" must be moved over and it itself inserted in the hole. With a negative value, it moves everything over, (the same behavior as if it had been '1') but since the value is negative, it puts it in a non-sequential index, instead of placing it in the newly-emptied place at index 1.


On Wed, Jan 23, 2013 at 10:06 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
2013/1/23 John Hind <john.hind@zen.co.uk>:
>
>>> The behaviour of table.insert and table.remove in Lua 5.2.1 is odd and
>>> not fully documented.
>
>>It was given an array with one entry (ie index 1) and asked to insert an
> invalid index (-10) >before it, therefore it moved index the current # entry
> to #+1.
>
> "therefore" (!?!)
>
> A spirited legal defence, Liam. However as an engineer I try to fix and
> improve things, not get my clients off on a legal technicality (or convict
> people). Trying to make software better is the highest compliment I know how
> to make a fellow coder: most software just is not worth this effort!
>

This subject is a hardy perennial. For example (by no means the only one)
look up the archives from mid-December 2010 to mid-January 2011, especially
the thread "Definition of table.insert", which only petered out after
Roberto said:

> May I ask the list to stop the discussion about arrays/holes/#/lists/
> table.insert?
>
> We have had hundreds of messages about this subject in less than a
> month. ...
>
> Please, avoid the vanity of thinking that your message will be the
> one to solve all the mess.