Makes sense. I took a look at what Saxon's XPath implementation does and it
looks like they promote things to longs for arithmetic, even int arithamtic. So
the likelihood of arithmetic overflow is pretty low.
This feels like the right approach and is similar to what you suggest, just
promoting
I also would be hesitant to cast every to to xs:integer, since our
implementation backs that with java.math.BigInteger. I would guess there's a
performance hit from switching to primitive types to BigInteger. Not sure if
that would be enough to notice though, especially since DPath epressions
aren'
immediately.
-Original Message-
From: Steve Lawrence
Sent: Monday, October 6, 2025 9:01 AM
To: [email protected]
Subject: Re: DPath arithmetic conversions and overflow/overflow
Makes sense. I took a look at what Saxon's XPath implementation does and it
looks like they pr
this communication is strictly prohibited. If you
have received this transmission in error, please notify the sender immediately.
-Original Message-
From: Steve Lawrence
Sent: Monday, October 6, 2025 9:01 AM
To: [email protected]
Subject: Re: DPath arithmetic conversions and ove
I couldn't find that phrasing about casting to an xs:integer in the spec. Maybe
AI hallucinated?
I did find this in the spec in Section B.1:
Note that type promotion is different from subtype substitution. For example:
A function that expects a parameter $p of type xs:float can be invoked
Ok, I looked at this and got some AI coaching
The phrase in the XPath spec says:
"If both operands are of type xs:integer or are derived from xs:integer,
then the operands are cast to xs:integer and the result is an xs:integer."
This is explicit about operands being derived from xs:integer
I'm trying to fix https://issues.apache.org/jira/browse/DAFFODIL-2574. The core
issue is that Java arithmetic operations return Int, even if for example you are
adding two Shorts. Our DPath implementation doesn't expect that, and assumes
xs:short + xs:short always result in an xs:short, that way
