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 in that part, but when it says they are cast, it doesn't qualify that in any way, so I think the right interpretation of this is that they are cast to exactly the xs:integer type. ChatGPT agrees: " XPath and XQuery .. deliberately avoid proliferating narrow integer subtypes in arithmetic results. Instead, the specification says: - For + - * div idiv mod, if both operands are subtypes of xs:integer, they are *promoted to xs:integer*, not kept at the narrower type. - That way, all arithmetic on integer subtypes collapses to xs:integer." - - Now, admittedly, I wrote a bunch of that code, and my thought would not have been to do that lazy thing of just casting everything to xs: integer. - Rather I would have wanted promotion to have been to the least common supertype for addition and multiplicatoin, and promotion to just the larger of the two arg types for division and subtraction of unsigned types. (Subtraction of signed types has to be treated like addition). - - So probably if we just did this promotion right the problem wouldn't occur. - - Certainly having short + short create short is a bug. - - I am wondering if I made the mistake of taking *least** upper bound* of the arg types, not least common supertype. The least upper bound of X and X is, well X. - - On Wed, Oct 1, 2025 at 2:18 PM Steve Lawrence <slawre...@apache.org> wrote: > 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 it knows all > the > types at compile time and can put in appropriate conversions. > > I was looking through the Xpath/XQuery spec to figure what the corret > behavior > is, and it feels kindof ambiguous. It defines arithmetic functions like: > > op:numeric-add($arg1 as numeric, $arg2 as numeric) as numeric > > But it doesn't really say what the resulting numeric should be. It really > just says > > op:operation(xs:integer, xs:integer) > > should return "xs:integer", but it's not completely clear if that's saying > the > result should be promoted to an xs:integer, or the result just should > derive > xs:integer. The later is my interpretation, suggesting we should not > promote, > and I think is what DPath intends. > > But that then has issues with underflow/overflow--what happens when a > short + > short doesn't fit into a short. Do we promote to an int? Do we error. The > spec > does say this regarding overflow underflow: > > For xs:integer operations, implementations that support limited-precision > integer operations ·must· select from the following options: > They ·may· choose to always raise an error [err:FOAR0002]. > They ·may· provide an ·implementation-defined· mechanism that allows users > to > choose between raising an error and returning a result that is modulo the > largest representable integer value. See [ISO 10967]. > > So we could just detect overflow and error, but that feels like short/byte > operations are likely to overflow. Which might break usability, but it > might > detect cases people weren't expecting? > > Or we could do what Java does and just promote arithmetic operations to > Int, > which is likely to just do the right thing and not overflow. But does me > you > would likely need to add downcasts that might not be expected,e.g. > > <element name="foo" type="xs:short" > dfdl:inputValueCalc="{ xs:short(../short1 + ../short2) }" /> > > In order for DPath to work the way it does, I think we do need to make a > compile > time decision, I don't think DPath really wants to promote things at > runtime to > whatever type fits the arithmetic result and just assume everything is a > Numeric. But I guess that could be an option too, and there just might be > little > bit of runtime overhead to check types and arithmetic results. > > Thoughts? >
