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 Friday, 29 January 2016 15:08:12 UTC