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

Reported here so that it gets on the agenda: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29419

> -----Original Message-----
> From: Abel Braaksma [mailto:abel.braaksma@xs4all.nl]
> Sent: Friday, January 29, 2016 4:08 PM
> To: 'Public Joint XSLT XQuery XPath'
> Subject: RE: Negative integer literals edge case scenario for negative
> underflow being an overflow
> 
> PPS: The obvious workaround, of course, is xs:integer("-
> 9223372036854775808"), which is allowed by the facets of the XSD type.
> 
> > -----Original Message-----
> > From: Abel Braaksma [mailto:abel.braaksma@xs4all.nl]
> > Sent: Friday, January 29, 2016 4:05 PM
> > To: 'Abel Braaksma'
> > Subject: RE: Negative integer literals edge case scenario for negative
> > underflow being an overflow
> >
> >
> >
> > From: Abel Braaksma [mailto:abel.braaksma@xs4all.nl]
> > Sent: Friday, January 29, 2016 3:53 PM
> > To: Public Joint XSLT XQuery XPath
> > Subject: 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.
> >
>

Received on Thursday, 4 February 2016 15:09:50 UTC