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

This might be a problem if the spec recognized 2^64 and -2^64 as boundary cases for xs:integer literals, but it doesn't. The range of xs:integer literals is implementation-defined.

The spec requires support for at least 18 digits - and an implementation that took that literally would not allow 9223372036854775808 anyway (I make it 19 digits).

The only place where 2^64 comes into play is for types such as xs:long; but we don't have xs:long literals in the language, you can only construct them from strings or xs:integer values, where the issue of "-" being an operator rather than part of the value doesn't arise.

So you may have an implementation issue here, but I don't think there is a spec issue.

Michael Kay
Saxonica

> On 4 Feb 2016, at 15:08, bugzilla@jessica.w3.org wrote:
> 
> 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 19:07:46 UTC