lua debug info

[Andreas Stenius <kaos@...>]

Hi,

I've run into a minor inconvenience with lua's debug info.
It's been present all along, but it's first now that I've
figured out enough to be able to give some insight to what
might actually be wrong.

The symptom:
The most obvious is when there's a bug in the lua code being
run (like indexing a nil value), and the error message names
the wrong variable as the one being nil, or indexed.

Later I found out that all my locals has the same name (from
the debug info point of view, it's working just fine from the
code side of things).

Like this piece of code:

function du_tostring( DU )
	local function get_arg(c)
		local m = math.imod
		local a = { DU/86400, m(DU/3600,24), m(DU/60,60), m(DU,60) }
		while c > 1 do
			c = c - 1
			table.remove(a, 1)
		end
		return unpack(a)
	end
	local function get_fmt()
		local s = { "%d days", "%d hours", "%d min", "%d sec" }
		local c =
			(DU >= 86400 and 1) or
			(DU >= 3600  and 2) or
			(DU >= 60    and 3) or 4
		return table.concat( s, ", ", c ), get_arg(c)
	end
	return DU and string.format( get_fmt() ) or "?"
end

Gives me this during a debug hook:
const/utils:du_tostring():142: locals
1       DU      60
2       DU      function: 14628c
3       DU      function: 147b04

where local 2 and 3 is the get_arg() and get_fmt() local functions resp.

This can be quite confusing when there's alot of locals, and an error occurs refering
to FOO, but you don't know which local it /really/ is.

I've only begun diggin' in the lua source trying to find what might cause this,
but have too little experince of the lua internals to become any wiser..

What might add to the confusion is that I'm running on a 16 bit system with these
sizes for the c types:
{
        ["char"] = 1,
        ["void *"] = 4,
        ["int"] = 2,
        ["short"] = 2,
        ["double"] = 8,
        ["float"] = 4,
        ["long"] = 4,
}

most notably it's the ints that isn't 4 bytes.. which is a common asumption.
(I've noticed though that they've {the lua authors, great work btw} made some
effort not to make this asumption, but there is a few places were it has failed).

//K