Re(2): xml.addValue bug?

[Jan M.J. Storms]

Eric Soroos scripsit dd. Fri, 14 May 2004 16:27:25 -0700

>
>On May 14, 2004, at 3:12 PM, Jan M.J. Storms wrote:
>
>> It must be a bug. If i move the table at adrXmlObj up closer to the top
>> level of the root, the truncation of the address disappears. However,
>> adrLabel remains unusable - it is just 7 levels deep, out of which 4 
>> are
>> serialized.
>>
>
>It's a 255 character address coercesion bug. If the full address of a 
>cell is more than 255 characters, you won't get it reported back as the 
>string representation of the address, but the address will still 
>generally work when used directly.
>
>I remember seeing this as far back as 2000, iirc.
>
>eric
>

I know the address to string coercion bug (all too well, lost a lot of
time figuring out why a perfectly good script suddenly would not function
properly), but these bugs are different. They show up in the return
values of xml.addValue and xml.getAddress, afaict.


This is the value of adrLabel: @scrat
chtable.["00005000\tpanel"].["00003000\titem"].["00002000\tlabel"], an
address of only 72 characters

I copied the source table to a local "scratchtable"; the element is at
system.compiler.stack.["level02: conv
ertWizard"].scratchtable.["00005000\t
panel"].["00003000\titem"].["00002000\tlabel"]. This path is only 120
characters.

But when i want to access adrLabel, I get the error message

Can't find a sub-table named "00002000	label".


Now if i use a table in a guest database, nested deeper, i get a value
for adrLabel like @["00002000\tlabel"], but even there the total length
of the address is below 160 characters. In that case it gets worse.

I hope these bugs which are in the kernel will be addressed quickly (not
years from now). It is not easy to build solidly with broken bricks.

Jan