Re: Oddity with tinsert (Lua 4.0)

["Jonathan Branam" <sspeare@...>]

I bet there are many other functions which have similar
behavior. What we would really need is a document
describing exactly what behavior the standard library
functions should conform to in cases such as this.

A similar situation could occur if you passed LESS
parameters to a function than it expected.

tinsert(t, 3)

would probably set the 3rd parameter to nil, which
isn't exactly obvious.

I wouldn't really call this a bug either. You are
passing an incorrect number of arguments to a
function. One could probably argue that it should
in fact take the last argument instead of the 3rd.
The function could also simply return error and
not do anything if you don't pass exactly 3
parameters because behavior is unknown.

Not that this changes anything, but it 4.1
I believe you could simply:

tinsert(t, 3, (gsub(...)) )

-Jonathan

----- Original Message -----
From: "Reuben Thomas" <rrt@dcs.gla.ac.uk>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Saturday, August 11, 2001 6:36 AM
Subject: Oddity with tinsert (Lua 4.0)


> If I run the following script:
>
> t = {}
> tinsert(t, 3, "hello", 1)
> print(t[3])
>
> I get:
>
> 1
>
> when I expect
>
> hello
>
> Looking at the source of luaB_tinsert in lbaselib.c, there appears to be a
> bug: the first line says:
>
>   int v = lua_gettop(L);  /* last argument: to be inserted */
>
> i.e. it always inserts tinsert's *last* argument, not its third.
>
> I was bitten by this because I was trying to execute a statement of the
form:
>
> tinsert(t, n, gsub(...)), and was getting the number of replacements
rather
> than the result of the replacement inserted. Surely this is wrong?
>
> Adding
>
> if (v > 3) v = 3; /* adjust to three args maximum */
>
> as the third line of the function cures the problem. Or have I
misunderstood
> something?
>
> --
> http://sc3d.org/rrt/ | egrep, n.  a bird that debugs bison
>
>