You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Python scribe when run on my machine (MacOS ARM64) produces little-endian txnums for hashXhistory prefix. (I just looked up M1 mac behavior, and it's little-endian by default) But there could be some more exotic platform that writes txnums big-endian fashion.
The endianness should be corrected to big-endian like other numbers in the database OR it should be locked to be little-endian specifically.
For now, I am correcting (herald.go) HashXHistoryValue implementation to read TxNums in little-endian form.
The text was updated successfully, but these errors were encountered:
This is a consequence of using an array.array('I'), which uses the native endianness. And I think it's actually worse - docs say It can be 16 bits or 32 bits depending on the platform. (https://docs.python.org/3/library/array.html).
Perhaps another library offers good enough performance and the ability to specify endianness, or we could make our own fast little endian uint32 array serializer/deserializer in cython.
Python scribe when run on my machine (MacOS ARM64) produces little-endian txnums for hashXhistory prefix. (I just looked up M1 mac behavior, and it's little-endian by default) But there could be some more exotic platform that writes txnums big-endian fashion.
The endianness should be corrected to big-endian like other numbers in the database OR it should be locked to be little-endian specifically.
For now, I am correcting (herald.go) HashXHistoryValue implementation to read TxNums in little-endian form.
The text was updated successfully, but these errors were encountered: