[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: UserData.
- From: Edgar Toernig <froese@...>
- Date: Wed, 31 Jan 2001 21:54:02 +0100
Roberto Ierusalimschy wrote:
> From: Edgar Toernig <email@example.com>
> > Maybe this change
> > - ts->u.d.value = (udata == NULL) ? uts+1 : udata;
> > + ts->u.d.value = s ? uts+1 : udata;
> > would make a little bit more sense. (There are other
> > problems too. Still thinking about a solution.)
> (The change is in lstring.c:122)
> I think his fix will solve the problem, although I don't know what
> would be the "other problems".
For userdata? Well, the LUA_ANYTAG stuff is IMHO bogus. You get
some random objects back. (I've simply removed it from Sol). The
other thing is with lua_settag. It's used to change the tag of
already existing userdata objects. The only valid way to use this
is IMHO to invalidate a userdata object. Any other usage may
generate duplicate objects with same udata/tag value and you no
longer know which one you get with lua_pushusertag. So I made
an invalidate function (that's a little bit trivial at the moment)
and restricted the use of anonymous userdata objects (= userdata
with default tag) to valid pointers.
But the "other problems" were not only about userdata. I was
twiddling with some other things at that time too. Some user
function are pretty fragile. Sometimes you may get unpredictable
results. I.e. tinsert(x,foo()): if foo returns more than one value
you either get an error or a broken list. Or dostring/dofile/call:
you don't know if the results come from the executed objects or from
the error handling.