[xslt] =?windows-1252?q?Bug_538580_=96_wrong_xpath_matching_on_te?= =?windows-1252?q?xt=28=29=5B_position-number_=5D?=



In looking at this bug, I tried just testing the XPath
behavior directly, and it seemed to do the right thing,
making me assume that the XSLT code was passing in the
wrong context positions.

That led me to pattern.c in the libxslt directory.
In the function xsltTestCompMatch(), it sure enough
looks like the code does context renumbering for
XSLT_OP_ELEM and XSLT_OP_ALL, but fails to do so
for XSLT_OP_TEXT. Thus, in template match patterns
like "text()[2]", it may produce erroneous results
when the current selection set contains non-text
nodes because it passes incorrect position numbers
to XPath.

I'm happy to take a stab at patching this (by cutting,
pasting, and tweaking one of the other two highly
similar position renumbering loops) if someone
with more experience with the code can a) confirm
this is the right place for a fix and b) review
the patch attempt (and (c) tell me what the heck
the tab settings are supposed to be in this
code, 'cause I sure can't find any that actually
make the indentation come out right!). Or,
if there's something else I can do to help get
the bug fixed, I'm happy to do that too.

I also don't see any renumbering going on for comments,
processing instructions, or named processing instructions.
Would those be bugs as well?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]