Exonum do not support big-endian architectures

[alekseysidorov]

At least two modules are implicitily assume that current hardware is little-endian.

• Storage
• Messages

It seems not to be critical issue because most of modern hardware is little-endian.

[defuz]

Why did you decide that? We use the byteorder crate and explicit conversions like LittleEndian::read_u32 and LittleEndian::write_u32 wherever the behavior between architectures may differ.

We must use a unified approach of -endianess for messages and storage data since it's protocol-specific behaviour and it is independent of the target architecture.

TLDR: The actual code should work on both architectures in the same way, but we did not test that.

Feel free to reopen issue.

[vldm]

@defuz yes, the code of u64/u16/u32 use byteorder::LittleEndian conversions, but SegmentFields slices, for example &[u64] &[u32] use transmute and Slice::from_raw which is not right way to represent architecture independent data.
@alekseysidorov reopen it pls

[dj8yfo]

@defuz reopen plz.

[defuz]

@vldm You know what to do :)

[dj8yfo]

@vldm, i assume this is covered now?