Binary test EXPath-binary-unpack-unsigned-integer-012

[michaelhkay]

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.

[adamretter]

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!

[johnlumley]

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 <#116 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE7QDrAVewGIw_KGLYKgzwV23LpdJ8HIks5uZksbgaJpZM4WgfYZ>.

-- *John Lumley* MA PhD CEng FIEE john@saxonica.com <mailto:john@saxonica.com> on behalf of Saxonica Ltd

[michaelhkay]

Saxon 9.8 and 9.9 are returning 18 446 744 073 709 551 615 and therefore failing the test...

[johnlumley]

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 ***@***.***> 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.

[ChristianGruen]

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?