Skip to content

Conversation

@fleupold
Copy link
Contributor

@fleupold fleupold commented Aug 3, 2023

Fixes @nlordell comment on #944

I don't think it's worth releasing a version with this, as the U256 from bytes documentation ensures it's always interpreted as big endian: https://docs.rs/uint/latest/src/uint/uint.rs.html#1363

Test Plan

KMS example still works

// By converting and encoding U256, we get rid of the leading zeros.
encoder.append(&U256::from(signature.r.as_bytes()));
encoder.append(&U256::from(signature.s.as_bytes()));
encoder.append(&U256::from_big_endian(signature.r.as_bytes()));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately H256 doesn't have as_big_endian (to make it clear that this is indeed compatible). Have to rely on the docs https://rust.velas.com/primitive_types/struct.H256.html#note

Copy link
Contributor

@nlordell nlordell Aug 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since H256 is just a [u8; 32], I don't think a concept of endianness makes sense... It is 32 bytes, so they are in byte order. At least this is my mental model around endianness.

@fleupold fleupold requested a review from nlordell August 3, 2023 09:15
@nlordell
Copy link
Contributor

nlordell commented Aug 3, 2023

I don't think it's worth releasing a version with this

Agreed. This was mostly about From not having a strict contract that "U256 from big endian bytes". It was mostly a nit about code intent.

@fleupold fleupold merged commit 15f0285 into main Aug 7, 2023
@fleupold fleupold deleted the 944_followup branch August 7, 2023 17:45
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

Successfully merging this pull request may close these issues.

3 participants