Negative integer literals edge case scenario for negative underflow being an overflow

If I understand the production rules correctly, we do not have a production for negative integer literals. An expression like -12 is essentially the unary minus operator with operand set to the positive xs:integer value 12.

 

This is in itself is not wrong, but it raises an interesting edge case for 64-bit restrained integer arithmetic (as opposed to unlimited integer precision). In such cases, the range of integers is -9,223,372,036,854,775,808  to +9,223,372,036,854,775,807.

 

If an implementation has such limit, it will not be able to interpret successfully the literal expression -9223372036854775808, it will first throw an out-of-range error on the positive integer literal, before it applies the unary minus operator.

 

This is most likely "by design" and I'm not even sure if there are any tests covering this, but I noticed it when testing certain edge cases with my XPath implementation, which currently only uses 64 bit integer ranges for xs:integer.

 

I don't think the same issue exists with xs:decimal, because IEEE allow the pos/neg range to be equal, i.e. for 128 bit decimals the range is -79,228,162,514,264,337,593,543,950,335 to +79,228,162,514,264,337,593,543,950,335 inclusive.

 

If the spec is supposed to allow the expression -9223372036854775808 without throwing an overflow error, perhaps we should make that explicit (but I don't know how, it seems to violate the current parsing rules).

 

Cheers,

Abel

 

PS: not raised as a bug because I am not sure it is one.