[Bug 29419] New: [XP31] edge case with negative integer literals (UnaryExpr) and limits for -9223372036854775808, which cannot be parsed

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29419

            Bug ID: 29419
           Summary: [XP31] edge case with negative integer literals
                    (UnaryExpr) and limits for -9223372036854775808, which
                    cannot be parsed
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3 & XPath 3 Test Suite
          Assignee: oneil@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

(this was previously reported to the joined mailing list:
https://lists.w3.org/Archives/Public/public-xsl-query/2016Jan/0038.html)

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-754 allows
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 any action needs to be taken here, I suspect that we only need to do
something if we agree that the literal (which currently isn't a literal but a
UnaryExpr) -9223372036854775808 should be accepted by implementers, even when
they pose a limit on integer ranges.

If we allow that expression to throw FOAR0002 then we need not do anything, I
think (unless someone things a Note is in order).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 4 February 2016 15:08:31 UTC