Bug #3521
closedIncorrect sign-extension in EXPath binary bin:unpack(-unsigned)-integer()
0%
Description
Logged by T Hata in https://saxonica.plan.io/boards/3/topics/7053:
Errors in unpacking binary integers with high bit set:
<unpack b="8000000000000000">
<signed>
<int size="0">0</int>
<int size="1">-128</int>
<int size="2">-32768</int>
<int size="3">-8388608</int>
<int size="4">-1</int>
<int size="5">-256</int>
<int size="6">-65536</int>
<int size="7">-16777216</int>
<int size="8">-1</int>
</signed>
<unsigned>
<int size="0">0</int>
<int size="1">128</int>
<int size="2">32768</int>
<int size="3">8388608</int>
<int size="4">2147483648</int>
<int size="5">549755813888</int>
<int size="6">140737488355328</int>
<int size="7">36028797018963968</int>
<int size="8">-9223372036854775808</int>
</unsigned>
</unpack>
It turns out that internally an int
constant, rather than a long
is used during sign extension calculation, which accounts for the error at 32-bit negative. The issue at 64 bit results from the sign extension or problems of holding an unsigned long
with the top bit set. This has been changed so that Big
representations are used above 7 byte unpacks.
Note that one of the EXPath QT3 tests, EXPath-binary-unpack-unsigned-integer-012, which unpacks all 64 bits set, has an incorrect assertion of value == -1, whereas it should be 18446744073709551615
Updated by John Lumley about 7 years ago
- Status changed from New to Resolved
Patches committed to 9.7, 9.8 and trunk.
This bug has been lying dormant fot 4.5 years!
Updated by O'Neil Delpratt almost 2 years ago
- Description updated (diff)
- Status changed from Resolved to Closed
Please register to edit this issue