Re: Some trivial questions about Lua 5.1.4 source

[Jim Pryor <lists+lua@...>]

On Mon, Jun 21, 2010 at 10:54:23AM -0300, Roberto Ierusalimschy wrote:
> > 1. In lobject.h, both the CommonHeader fragment and the lua_TValue
> > struct have a "tt" field. I take it this means "type tag". However, why
> > is it a lu_byte-sized field in CommonHeader and a int-sized field in
> > lua_TValue?
> > I realize that that the type tag enumerations will always be less than
> > lu_byte-sized.
> >  And I don't think these two types are ever applied to a single block
> >  of data; if I understand right, CommonHeader is always part of a
> >  heap-allocated structure, and TValues are small objects (booleans,
> >  numbers, pointers). But why do the declarations vary? Is that
> >  deliberate? Is there a reason for it?
> 
> CommonHeader is always part of a heap-allocated structure. That is why
> its tt is a byte (and why CommonHeader is not a structure itself);
> sometimes the structure defines other bytes and we do not lose memory
> due to allignment (e.g., 'isC' and 'nupvalues' in closures). TValues are
> complete structures that represent all values in Lua (including pointers
> to heap-allocated objects with a CommonHeader). They are not part of
> other structures. Again due to allignment, tt will require sizeof(int)
> (or even sizeof(double)) bytes there, so it is simpler to keep it an int
> (the basic integer type in C).

Thanks for the responses. This is basically what I expected.

> > 2. A TValue is a type-tagged Lua object. Some fields point to Lua
> > objects, themselves, directly, rather than to TValues. For instance, in
> > lstate.h, struct global_State.mt is a array of pointers to to Tables,
> > rather than an array of pointers to
> > Tables-wrapped-as-TValues-with-a-LUA_TTABLE-tag. OK.
> >     Now I'm a bit puzzled by why struct lua_State.l_gt and .env are
> > TValues rather than simply Table*s. There isn't much space difference,
> > but I was puzzled whether there was a reason, given that in some other
> > cases simple Table*s were used. Perhaps the reason is that those two
> > fields are exposed in the Lua environment? But there's also a third
> > case: struct global_State.l_registry is also a TValue not a Table*.
> > That's not normally exposed in Lua. Granted,  one can make it exposed.
> > But then, the elements of struct global_State.mt can also be exposed
> > through debug calls, and they're Tables not TValues. So I was wondering
> > whether there was any principle governing when TValues were used and
> > when the type-untagged Lua objects themselves (or pointers to them) were
> > used.
> 
> When space is important (that is, almost any other structure out of
> lua_State), we try to use pure pointers.
> 
> Otherwise, each of these cases is a TValue or a direct pointer depending
> on its usage. For instance, l_registry being a TValue simplifies its
> handling as a pseudo-index in the C API (see function 'index2addr').

Again, thanks for the explanation, I appreciate it.

-- 
Jim Pryor
profjim@jimpryor.net