A small bug with textutils.serialize...

Now, textutils.serialize protects itself from recursion, but if the same table is inside another table which is not a child of itself, it still errors.

Sounds confusing?

local t1 = {"lol"}
local t2 = {{t1},{t1}}
print(textutils.serialize(t2))

The above program WILL fail with "Cannot serialize table with recursive entries"!
And as you can see, it isn't recursive.
Thats because when the main serialization function (serializeImpl) serializes a table, it adds it to tTracking when it enters the table, but not when it exits.
Adding "tTracking[t] = nil" above "return result" would fix this.

Why would you need to serialize a table with recursive entries?

SuicidalSTDz, on 24 March 2013 - 03:09 PM said:

Why would you need to serialize a table with recursive entries?

The point he is trying to make is it is not recursive, it just has the reference to the same table twice, which textutils THINKS is recursive when it is not.

Ah, I see now. Makes sense.

Off topic: I had the oddest dream where Lyqyd and Cloudy were flooding the forum with os's to get back at the clueless members…

Don't give me ideas!

Anyway, serialize needs work. Considering adding a new method for serializing and handling old and new serialize formats in unserialize.

There was a serialize function that worked with recursive tables someone made in the forum. It's really old, so it's probably deep down in the programs section :P/>
Just need to find a way to use it without breaking current serialization (maybe add a header or something?).

Cloudy, on 24 March 2013 - 03:32 PM said:

Don't give me ideas!

Hehe. I could see you doing it B)/>

On topic: I've never tried to do this with textutils so this won't ever be a problem with me :P/>

You're probably thinking of immibis' [Api] Proper Serialization.

As posted, it has an off-by-one bug. In deserialize, "pos = pos + 1" needs to be "pos = pos + 2". Other than that, it passed all the quick-and-dirty tests I threw at it.

One potential pitfall though is that the serialization is not human-readable, so it is not 100% compatible with textutils.serialize. If textutils.serialize was replaced with it, any scripts that depend on the output being human-readable (tricks with loadstring, dofile, etc) would break. I doubt that many scripts rely on this behavior :shrug: