Serialization of time classes in fc is architecture-dependent

[pmconrad]

Bug Description
The (binary) serialization of fc::time_point, fc::time_point_sec and fc::microseconds is architecture-dependent (big-endian vs. little-endian).

Impacts
Describe which portion(s) of BitShares Core may be impacted by this bug. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

Within our x86-dominated ecosystem the bug has no effects. However, it will be impossible to sync a node on a big-endian machine.

Steps To Reproduce
n/a

Expected Behavior
Serialization should be architecture-independent.

Host Environment
all

Additional context
https://github.com/bitshares/bitshares-fc/blob/master/include/fc/io/raw.hpp#L93-L132

CORE TEAM TASK LIST

• Evaluate / Prioritize Bug Report
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[pmconrad]

Might be a good idea to scan for similar problems in other areas.

[clockworkgr]

Are there many/any big-endian machines left? apart from IBM mainframes?

[jmjatlanta]

Anyone have a spare mainframe linux partition to test this with? I'd love to port and see some performance numbers on some recent IBM power or z hardware.

[pmconrad]

More candidates: all the hash classes in fc::crypto use uint32 or uint64 arrays as a buffer for storing the hash. This is mostly fine, but sometimes an element of these buffers is accessed directly, which leads to architecture-dependent results. See sha256::hash64().

The way the block number is stored in the block ID attempts to be clean, see https://github.com/bitshares/bitshares-core/blob/master/libraries/chain/protocol/block.cpp#L43 . However, fc::endian_reverse_* reverses the byte order always, not in an architecture-dependent way... https://github.com/bitshares/bitshares-fc/blob/master/include/fc/bitutil.hpp

TODO: check all usages of fc::endian_reverse_*

[christophersanborn]

Are there many/any big-endian machines left? apart from IBM mainframes?

Apparently ARM can run in either little- or big-endian mode, according to this quote from here:

"The ARM architecture was little-endian before version 3. Since then ARM processors became BI-endian and feature a setting which allows for switchable endianness."

I don't know how easily "switchable" it is, like if it's a start-up option determined in essence by the OS, or if programs can switch on-the-fly,... but if somebody wants to run a personal access node on a Raspberry Pi, or maybe someday as an applet on their WiFi router, then this issue may have some relevance.

[pmconrad]

Resolved by #1714