Bounds checking for xs:integer is broken.

[LeoWoerteler]

BaseX uses double calculations in order to check if 64-bit long calculations overflow. As IEEE754 doubles only have 53 significant binary digits but operations on long need up to 128, this is unsafe:

-9223372036854775807 - 1024 silently underflows to 9223372036854774785 even though the boundary check in org.basex.query.expr.Calc is in place.

[LeoWoerteler]

More weirdness:

let $P63 := xs:decimal('9223372036854775808'),
    $P64 := $P63 + $P63
return $P63 - $P64 idiv 2

Should return 0, but returns 1 instead.

[LeoWoerteler]

The following checks could be used: https://www.securecoding.cert.org/confluence/display/java/NUM00-J.+Detect+or+prevent+integer+overflow#NUM00-J.Detectorpreventintegeroverflow-PreconditionTesting

[LeoWoerteler]

More optimized: https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/math/LongMath.java

[LeoWoerteler]

Related: -9223372036854775808 is a valid xs:integer constant, but it cannot be parsed because it is parsed as -(9223372036854775808) and 9223372036854775808 is not in range. This is quite confusing, because -9223372036854775807 - 1 works fine.

I don't think this is easy to fix because the unary minus has a ValueExpr as argument, which can e.g. be a SimpleMapExpr: -1 ! 2 ! 3 is parsed as -(1 ! 2 ! 3), not (-1) ! 2 ! 3. This means that we cannot just look ahead if the next token after the - is a number.

A solution would be to parse an integer literal 123 as xs:integer('123') and let the optimizer do the evaluation. Then we could look for the pattern -(xs:integer('9223372036854775808')) and evaluate it at parse time.

[ChristianGruen]

The bugs of the first two comments are resolved; the last observation could be resolved by introducing BigInt instances (the cast proposal leads to wrong error codes, FORG0001 instead of FOAR0002).