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:


Result is as expected:


Now near the same XSieve fragment:


But the result made me crazy:


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