nasty libxslt surprise

Libxslt optimizes "xsl:text", but there is no mention of the optimization neither on the site of libxslt, neither in its mailing list. I've got the knowledge from the deep debugging session. Should I hate libxslt, or should I love it for its puzzles?

See what has happened.

A fragment of an XSieve program:

<x>
  <x:text>[[[</x:text>
  <s:scheme>"123456789"</s:scheme>
  <x:text>]]]</x:text>
</x>

Result is as expected:

<x>[[[123456789]]]</x>

Now near the same XSieve fragment:

<x>
  <x:text>[[[</x:text>
  <s:scheme>"12345678"</s:scheme>
  <x:text>]]]</x:text>
</x>

But the result made me crazy:

<x>[[[]]]</x>

Fortunately, gdb helped me. I traced libxslt and found very interesting fields in the XSLT context structure:

* const xmlChar * lasttext : last text node content
* unsigned int lasttsize : last text node size
* unsigned int lasttuse : I don't know

The first "x:text" was creating a text node and setting the last-variables. "s:scheme" was adding a text to the node, but was not updating the variables. (How could I know about it?) The second "x:text" was using data from the variables, therefore result of "s:scheme" was losing. I applied the simplest fix: after executing "s:scheme", I reset "lasttext" to NULL.

I still don't understand why the losing happened only for short strings. Probably it's somehow related to the variable "lastuse". But I don't care.

Categories: XSieve

Updated: