-
Notifications
You must be signed in to change notification settings - Fork 59
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
Don't hardcode endianness #283
Labels
Comments
sarroutbi
added a commit
to sarroutbi/rust-keylime
that referenced
this issue
Aug 11, 2023
Resolves: keylime#283 Signed-off-by: Sergio Arroutbi <[email protected]>
sarroutbi
added a commit
to sarroutbi/rust-keylime
that referenced
this issue
Aug 11, 2023
Resolves: keylime#283 Signed-off-by: Sergio Arroutbi <[email protected]>
sarroutbi
added a commit
to sarroutbi/rust-keylime
that referenced
this issue
Aug 11, 2023
Resolves: keylime#283 Signed-off-by: Sergio Arroutbi <[email protected]>
sarroutbi
added a commit
to sarroutbi/rust-keylime
that referenced
this issue
Aug 11, 2023
Resolves: keylime#283 Signed-off-by: Sergio Arroutbi <[email protected]>
Check if this is actually valid: the encoding is kept the same independently of the arch to avoid encoding errors due to endianess. A good approach to check is to test the changes proposed in #637 mixing big endian and little endian arches |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Use the host endianness instead of
to_le_bytes()
orto_be_bytes()
. I think there is an easy way to do this frombyteorder
but I'd have to look again.The text was updated successfully, but these errors were encountered: