Bug #427
closed
Variables in patterns overwrite those in calling template
0%
Description
SourceForge user: clistheret
I've an xslt document that uses a selector something
like the following:
[$g = string-join(for $n in ancestor-or-self:: return
concat('/', name($n), '[',
string(count($n/preceding-sibling::*[name(.) =
name($n)]) + 1), ']'), ''))]
to find certain nodes given by parameters.
This selector seems to be runing variables that I
defined before this point. It's a bit difficult to
explain, as I'm not sure what is happening behind the
scenes. Run the provided xml through the provided xslt
and see what happens.
My output looks like (spacing excluded):
testvar: "the text to begin with"
testvar: "col2"
testvar: "data2"
There is no reason that the value of testvar should change.
Files
Updated by Anonymous over 20 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Thanks for reporting this (although you somehow failed to
notice the bright yellow box that says this isn't the right
way to report suspected bugs: I prefer to use this section
of the site to explain confirmed bugs. Even where it's a
real bug, as here, it's easier for users generally if the
entry starts with the description of the bug after analysis).
What's happening is that apply-templates makes a decision
whether to create a new stack frame for evaluating patterns
in template rules, and it's getting this decision wrong in
this case, so the variables in the pattern are being written
using slots in the same stack-frame as the template
containing the apply-templates instruction. As a
circumvention, do the call indirectly via another template
(which should define a dummy variable).
As it happens I have already redesigned this area for 8.1
and the bug went away in the process.
Test case added: match54
Updated by Anonymous over 20 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Another related problem has been found (saved as test case
match55). This happens when the variables are not used
explicitly in the match pattern, but are introduced by the
optimizer. This example showed different syptoms: an
ArrayIndexOutOfBoundsException. This problem was still
present in the redesigned code, but has now been fixed.
Please register to edit this issue
.