-
Notifications
You must be signed in to change notification settings - Fork 7
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
incompatibilities with big-endian target platforms / CPU architectures #36
Comments
This is the same algorithm that cargo uses, is cargo not packaged for that target as well? u64 hash -> bytes bytes -> string I can of course fix this so it is consistent for big endian targets, but AFAICT the directory will be different on big endian machines, according to cargo's own tests I think the best option is to to do the same as cargo and ignore the tests on big endian machines, the tests are just to verify we match cargo, if they pass on little endian they will also match on big endian. |
Just as [cargo does](https://github.com/rust-lang/cargo/blob/0871c0e2f4b6d4f95b7408fb8cef8ad3c9c8d834/src/cargo/core/source_id.rs#L930-L936), ignore the 2 tests that depend on the target being little endian. Resolves: #36
Oh, of course, if cargo does the exact same thing, then the results will match (even if they are different depending on architecture endianness) ... thanks for the clarification and the "fix" :) 👍🏼 |
The hexadecimal part of cargo index paths is different on little- and big-endian architectures. See also EmbarkStudios/tame-index#36 I have verified that the endianness-specific `CRATES_IO_SPARSE_DIR` definition is correct and indeed matches what cargo writes to on big-endian architectures.
I'm working on packaging this crate for Fedora Linux as a dependency of cargo-deny / cargo-audit. I noticed that tests fail on one of our officially supported architectures - the only big-endian architecture we support, s390x / IBM System Z.
From the output of
cargo test --release
(plus a few more distribution-specific flags):From what I can tell, this is caused by this function:
https://github.com/EmbarkStudios/tame-index/blob/0.7.1/src/utils.rs#L18-L37
I think this chunk of code does not produce the same results on little-endian and big-endian architectures, and will produce results that are unexpectedly "shuffled" according to the different byte order:
The text was updated successfully, but these errors were encountered: