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
For network protocols, there is an established convention to encode integers as big endian. Borsh isn't designed specifically for network protocols, but with its compactness and its other nice properties, it's also fairly well-suited for defining network protocols.
Implementation wise, after reasoning through a few different stragies, I believe it would make the most sense to implement this by defining an attribute that can be defined on a struct or a field that has a #[derive(BorshSerialize, BorshDeserialize)] to indicate the integer encoding policy just for integers in that scope. This is fairly backwards compatible and allows types with little endian integers to be used interchangeably mixed in with types that use big endian ones.
The text was updated successfully, but these errors were encountered:
For network protocols, there is an established convention to encode integers as big endian. Borsh isn't designed specifically for network protocols, but with its compactness and its other nice properties, it's also fairly well-suited for defining network protocols.
Implementation wise, after reasoning through a few different stragies, I believe it would make the most sense to implement this by defining an attribute that can be defined on a struct or a field that has a
#[derive(BorshSerialize, BorshDeserialize)]
to indicate the integer encoding policy just for integers in that scope. This is fairly backwards compatible and allows types with little endian integers to be used interchangeably mixed in with types that use big endian ones.The text was updated successfully, but these errors were encountered: