Re: Strong tables in Lua 5.4

[Sean Conner <sean@...>]

It was thus said that the Great Sean Conner once stated:
> It was thus said that the Great Roberto Ierusalimschy once stated:
> > > Every `t[k] = f()` of every module and dependency (and their
> > > dependencies recursively) would have to be checked for memory leaks.
> > > And this won't be the typical Lua 5.x to Lua 5.(x+1) situation where
> > > you try out a dependency on a new Lua version and it doesn't) build
> > > because lua_dump now has an extra argument, or lua_objlen was renamed
> > > to lua_rawlen in a Lua/C module, or you get a crash with a stack trace
> > > in your testsuite because setfenv() doesn't exist anymore.
> > 
> > I still think you are exaggerating the problem, but I may be wrong. I
> > would like to know how many real programs have the construction
> > t[k] = f() where f() returning 'nil' is not a bug. (You mentioned
> > that table.move could create that kind of thing. I asked for a real
> > scenario, but got no answer.)
> > 
> > More concretely, I propose a little experiment: suppose that Lua raises
> > a run-time error for every assignment of nils to tables except in
> > explicit assignments with a constant nil (t[k]=nil). How frequently this
> > error will occurr without hinting a hidden bug in the code? (Please,
> > any answer should be about some piece of real, useful code where that
> > could happen.)
> 
>   Less than a minute in, and I found a place what would break code I've
> written (for work no less!).
> 
>   I have the following function:
> 
> 	-- Okay, we store a coutine and arguments into a table for later
> 	-- running the it.
> 
> 	function schedule(co,...)
> 	  RQUEUE[#RQUEUE + 1] = { co, ... }
> 	end
> 
> then later down in the code I have the following:
> 
> 	-- We've timed out on waiting for something.  signal the error by
> 	-- returning nil and and error of TIMEDOUT
> 
> 	schedule(obj.co,nil,errno.ETIMEDOUT)

  I'm replying to this to say that I might have found a bug in that code and
that it works is a quirk of the implementation.  I went further down the
code to where I actually run the coroutine and lo, I found:

	local okay,err = coroutine.resume(unpack(obj))
	-- obj is a bad name but that's beside the point!

  The 'obj' table contains:

	{ co , nil , errno.TIMEDOUT }

and I suppose because of the binary search nature of determining the length,
this works!  Wow!  I think I was concentrating on the Happy Path (TM) that
the undefined nature of length in the presence of holes skipped me entirely.

  -spc