expath-cg
expath-cg copied to clipboard
expath
Binary test EXPath-binary-unpack-unsigned-integer-012
The test is
bin:unpack-unsigned-integer(xs:base64Binary(xs:hexBinary('ffffffffffffffff')),0,8,'most-significant-first')
and the expected result is -1.
We are getting the result 18 446 744 073 709 551 615 which seems correct to me.
I also interpret the EXPath Binary spec to mean that the result should be 18 446 744 073 709 551 615.
I note that BaseX (8.6.7) returns -1.
In Java 0xffffffffffffffffl == -1, but that is a signed representation!
Very dim recollections of putting this test together - was it all of 5 years ago? It was of course tested on Saxon's Java framework and examining the code looks as if for anything up to 8 octets, which this is, uses a long for return - hence it would end up being signed as the top bit is set. Thus incorrectly Saxon was passing the incorrect test and I suspect BaseX has done similar. Beyond 8 octets a BigInteger is used. This would of course be the case only for, and always, with an 8 octet extraction with the top bit set. Surprising no-one seems to have uncovered this in 5 years.
When I have some time I'll modify the test and alter the Saxon implmentation to use Big for such cases.
On 10/09/2018 12:20, Adam Retter wrote:
I also interpret the EXPath Binary spec to mean that the result should be 18 446 744 073 709 551 615.
I note that BaseX (8.6.7) returns |-1|.
In Java |0xffffffffffffffff|l == -1, but that is a signed representation.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/expath/expath-cg/issues/116#issuecomment-419879468, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7QDrAVewGIw_KGLYKgzwV23LpdJ8HIks5uZksbgaJpZM4WgfYZ.
-- John Lumley MA PhD CEng FIEE [email protected] mailto:[email protected] on behalf of Saxonica Ltd
Saxon 9.8 and 9.9 are returning 18 446 744 073 709 551 615 and therefore failing the test...
Did my response to the list get through? Sometimes I don't see the response. Actually think about it - I was wrong - above 7 octets, not 8, we use a BigInteger.
Sent from my iPad
On 10 Sep 2018, at 13:17, Michael Kay [email protected] wrote:
Saxon 9.8 and 9.9 are returning 18 446 744 073 709 551 615 and therefore failing the test...
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.
Hi all, I agree, BaseX returns the wrong result here.
As @johnlumley already guessed (thanks), it is because items of type xs:integer are limited to long values in BaseX. Maybe the specification would need to be enhanced to handle numeric overflows/underflows and to allow errors similar to FOAR0002?
