<p><code>ser_writedata8</code> does not care about endianness, in contrast to <code>ser_writedata16</code>, <code>ser_writedata32</code>, <code>ser_writedata64</code>. Single bytes don't need to swapped, as <a href="https://stackoverflow.com/questions/16803397/can-endianness-refer-to-bits-order-in-a-byte">8 bits have one address</a> and there's no way to access specific bits without using BMI or arithmetic operations. Therefore, bit endianness is not important except in <a href="https://stackoverflow.com/a/16804571/6557621">bitfields</a>.</p>

CC BY-SA 4.0
2018-12-14T16:58:40.090Z
I know 1 byte doesn't need endianness flips. I just couldn't see how the flipping is being done.
The Quantum Physicist
CC BY-SA 4.0
2018-12-14T17:03:05.673Z
@TheQuantumPhysicist For example, `Serialize(Stream& s, uint16_t a)` calls `ser_writedata16`, which calls `htole16(obj);`. `htole16` does the bswap there.
MCCCS
CC BY-SA 4.0
2018-12-14T16:45:38.947Z
2018-12-14T16:45:38.947Z
MCCCS
<p>It should work on big-endian systems. The serialization code for integers will byteswap on such systems. This was certainly tested at some point, but I'm not sure how recently someone has.</p>

<p>I don't think it will work on systems where int is different than 32-bit.</p>

CC BY-SA 4.0
2018-12-14T16:39:03.773Z
2018-12-14T16:39:03.773Z
Pieter Wuille
<p>Looking at the source code of bitcoin core, <a href="https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L195" rel="nofollow noreferrer">the serialization part</a>, I see that there's no serialization abstraction layer that accounts for a possible different endianness or different binary layouts on different machines.</p>

<p>This is not only for disk serialization, but also for network serialization. 
If bitcoin core was used on a big-endian machine, or a machine with <code>int</code> size not equal to 32-bit, it'll fail to connect to the network because all sizes will be incorrectly interpreted and values will be different.</p>

<p>Am I missing something or did I arrive at the correct conclusion?</p>

CC BY-SA 4.0
2018-12-14T17:27:13.080Z
The byteswap has been addressed in MCCCS's answer (it's done by `htole16` and the like).  For the word size, can you explain specifically what you think is wrong?  That code appears, at first glance, to make proper use of the `uintNN_t` types.
Nate Eldredge
CC BY-SA 4.0
2018-12-14T19:56:06.693Z
@NateEldredge Many of the data structures being serialized use int/long/short/..., and serialize those directly. The serialization code per se does the right thing, but the data being serialized wouldn't.
Pieter Wuille
<bitcoin-core><client><development><network><full-node>
Would bitcoin core work on a big endian system? Or even a system where C++'s `int` is not 32-bit?
The Quantum Physicist
# Would bitcoin core work on a big endian system? Or even a system where C++'s `int` is not 32-bit?

(Asked by: username_0 on 2018-12-14)

Looking at the source code of bitcoin core, [the serialization part](https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L195), I see that there's no serialization abstraction layer that accounts for a possible different endianness or different binary layouts on different machines.

This is not only for disk serialization, but also for network serialization.
If bitcoin core was used on a big-endian machine, or a machine with `int` size not equal to 32-bit, it'll fail to connect to the network because all sizes will be incorrectly interpreted and values will be different.

Am I missing something or did I arrive at the correct conclusion?

**Tags:** bitcoin-core, client, development, network, full-node

> **Comments:**
> **username_1**: The byteswap has been addressed in username_3's answer (it's done by `htole16` and the like).  For the word size, can you explain specifically what you think is wrong?  That code appears, at first glance, to make proper use of the `uintNN_t` types.  
> **username_2**: @username_1 Many of the data structures being serialized use int/long/short/..., and serialize those directly. The serialization code per se does the right thing, but the data being serialized wouldn't.  

---

## 2 answers

### Answer by username_3 on 2018-12-14. Score: 1 | Accepted answer

`ser_writedata8` does not care about endianness, in contrast to `ser_writedata16`, `ser_writedata32`, `ser_writedata64`. Single bytes don't need to swapped, as [8 bits have one address](https://stackoverflow.com/questions/16803397/can-endianness-refer-to-bits-order-in-a-byte) and there's no way to access specific bits without using BMI or arithmetic operations. Therefore, bit endianness is not important except in [bitfields](https://stackoverflow.com/a/16804571/6557621).

> **Comments:**
> **username_0**: I know 1 byte doesn't need endianness flips. I just couldn't see how the flipping is being done.  
> **username_3**: @username_0 For example, `Serialize(Stream& s, uint16_t a)` calls `ser_writedata16`, which calls `htole16(obj);`. `htole16` does the bswap there.  

---

### Answer by username_2 on 2018-12-14. Score: 2

It should work on big-endian systems. The serialization code for integers will byteswap on such systems. This was certainly tested at some point, but I'm not sure how recently someone has.

I don't think it will work on systems where int is different than 32-bit.


---

