lljson.sldecode can produce uncompressed uuids
planned
Tapple Gao
lljson has inconsistent behavior. I think these should all produce an error:
print(pcall(lljson.sldecode, '"!vOops"'))
print(pcall(lljson.sldecode, '"!qOops"'))
print(pcall(lljson.sldecode, '"!uOops"'))
The first 2 produce an error:
malformed tagged vector: !vOops
malformed tagged quaternion: !qOops
But the last one produces an uncompressed uuid:
local _, u = pcall(lljson.sldecode, '"!uOops"')
print(u, typeof(u), u.bytes) -- Oops uuid nil
This uuid cannot be re-encoded:
print(pcall(lljson.slencode, u))
invalid UUID format for JSON encoding
Instead,
sldecode
should produce an error:malformed tagged uuid: !uOops
And uncompressed uuid's should be removed from slua, it's documentation, and typechecker: https://github.com/secondlife/lsl-definitions/blob/23d46484888c1908545dc92db119613bb553af11/slua_definitions.yaml#L70
- name: bytes
comment: Returns the raw 16-byte binary string of the UUID, or nil if the UUID
is not in a compressed state
type: string?
Log In
H
Harold Linden
marked this post as
planned
Thanks! Yeah, this is left over from when before we took out all paths in SLua proper that could legitimately create non-normative UUIDs (
link_message
events, basically, since id
is now a string
).Tapple Gao
Another way to get an uncompressed uuid in slua:
local u = ll.List2Key({"Oops"}, 1)
print(u, typeof(u), u.bytes) -- Oops uuid nil
print(lljson.slencode(u)) -- invalid UUID
I'd be ok with deprecating or removing this function outside llcompat
Tapple Gao
If uncompressed uuid's need to be kept around for the lsl vm, I'd still prefer they were removed from documentation/typechecker, and consider it a bug if they ever get exposed in slua
WolfGang Senizen
Personally I'd prefer matching the casting behavior of the same as
tovector
touuid
toquaternion
functions, instead of an error for any of them.Vaguely along the principle of being forgiving with what input you accept but accurate with what you output produce.
Tapple Gao
I prefer fail early for lljson.sldecode rather than finding an unexpected nil in one of my arrays later. It already needs wrapping in pcall for other reasons
H
Harold Linden
WolfGang Senizen
> Vaguely along the principle of being forgiving with what input you accept but accurate with what you output produce.
Having dealt with a number of lower-level RFCs and their implementations, Postel's Law is something we're still desperately trying to recover from