Make endianness of our feature flag bitfields more intuitive

[valentinewallace]

Currently, when we store feature flag bitfields in e.g. the Peer struct, we store them such that the bytes overall are in little-endian order, but each individual byte is big-endian.

I.e.:
peer.their_features: [[feature bit 7, feature bit 6, ... feature bit 1, feature bit 0], [feature bit 15, feature bit 14, ... feature bit 8], [feature bit 18... feature bit 16]]

It'd be more intuitive if each individual byte were also little-endian.

Mostly filing this for myself as a potential future refactor.

[TheBlueMatt]

Hmmm, we could do this, but swapping bit order at read is a bunch more work and once we do that we have to start doing arithmetic to figure out which bit to read, instead of only doing arithmetic to figure out which byte to look at. Nomenclature note: there is no such thing as an LE byte, though I get what you meant here.

…

On Mar 10, 2020, at 11:38, valentinewallace ***@***.***> wrote:  Currently, when we store feature flag bitfields in e.g. the Peer struct, we store them such that the bytes overall are in little-endian order, but each individual byte is big-endian. I.e.: peer.their_features: [[feature bit 7, feature bit 6, ... feature bit 1, feature bit 0], [feature bit 15, feature bit 14, ... feature bit 8], [feature bit 18... feature bit 16]] It'd be more intuitive if each individual byte were also little-endian. Mostly filing this for myself as a potential future refactor. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[valentinewallace]

Hmm ok, maybe not worth. Feel free to close!

[jkczyz]

Closing this since #590 should make this less problematic.