Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HashXHistoryPrefixRow issue with endianness of TxNums written to DB #91

Open
moodyjon opened this issue Sep 1, 2022 · 1 comment
Open

Comments

@moodyjon
Copy link
Contributor

moodyjon commented Sep 1, 2022

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.

@jackrobison
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants