Simply moving to a 64-bit long would allow an InputStream that would take a
million years or so to process, which is infinite enough for most people.
This particular limit is easy to fix. There are others that are harder: 32-bit
limits on the size of sequences and strings are scattered throughout Saxon not
to mention the Java VM itself. One example: a streamable stylesheet can call
position() to get the position of the current node, and position() is a 32-bit
int. Similarly xsl:number uses 32-bit integers. Moving to 64 bits everywhere
would be a significant challenge, not least because of the difficulty of
testing all paths with the large data volumes needed to find the bugs.
Michael Kay
Saxonica
On 14 Jun 2018, at 06:19, Mukul Gandhi
gandhi(_dot_)mukul(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi Mike,
On Wed, Jun 13, 2018 at 1:00 PM, Michael Kay mike(_at_)saxonica(_dot_)com
<mailto:mike(_at_)saxonica(_dot_)com>
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>> wrote:
The Saxon implementation does have some limits that mean the input stream
can't be infinite: most obviously, the nodes are numbered using a 32-bit
integer.
Can't Saxon use java.math.BigInteger instead of the 32-bit integer data type?
(if 32-bit integer constraint is not allowing Saxon to process theoretically
infinite size input stream).
--
Regards,
Mukul Gandhi
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <-list/293509> (by email <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--