xsl:apply-templates is a call, just like call-template, and it requires
a new stack frame.
(Actually with Saxon the situation is a little more complex. Saxon uses
the Java stack to handle the calling structure and return address, and
it uses its own stack, which lives in the Java heap, to handle XSLT
parameters and local variables. If you call a template that has no
variables or parameters, then no stackframe is allocated on Saxon's
stack, but it still uses some space on the Java stack to keep track of
the calling hierarchy and return address. When tail-calls are optimized,
which isn't happening here, both stacks are unwound before making the
call.)
Michael Kay
Software AG
home: Michael(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
Bill Cohagan
Sent: 02 April 2003 21:51
To: XSL-List(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] Parser implemented in XSL -- stack overflow
Michael-
You say:
===================
The call:
<xsl:apply-templates select="following-sibling::*[1]" mode="sn5">
<xsl:with-param name="parents" select="concat($ID, ',',
$adjustedParents)" />
</xsl:apply-templates>
will generate a new stack frame for each sibling that is
processed. ====================
I assume that it's not simply the <xsl:apply-template ...>
call that pushes stack. What is it about my code that causes
stack push? Is it the select expression, the mode, or the use
of a param?
Thanks,
Bill
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list