Endianness of "int"?

[James-E-A]

I want to pull raw ints and uints — that may be wacky sizes like 12 or 5, rather than whole-byte sizes — from a very tightly packed bitstream.

However, I'm wondering: is the endianness of these formats guaranteed?

For example, on my machine (Windows on x86_64), this holds:

assert Bits(b'\x00\x10\x10').unpack(['int : 12', 'int : 12']) == [1, 16],\
       "It looks like the 'int:n' format string isn't big-endian on this system!"

The documentation didn't say anything either way about this:

Bits.int: int

Bits.i: int

Property for the signed two’s complement integer representation of the bitstring.

[scott-griffiths]

Hi. Yes the endianness of the formats is guaranteed.

System big or little endianness is only ever at the byte level, and determines which order the bytes are arranged before interpreting them. There are explicit data types for each of these, e.g. intbe, intle, intne for big, little and native endian signed ints. Note that these types can only work if the interpreted data is a whole number of bytes long, as otherwise it just doesn't make sense.

The ordinary int is bit-wise big-endian, which just means that the right-most bit is the least significant. The int12 is therefore just bit-wise big endian, and will be the same everywhere.

I'd suggest taking a look at how numbers are stored as big and little endian in the struct module - the concept doesn't make sense in the same way for 12 bit numbers.

[James-E-A]

The ordinary int is bit-wise big-endian

Ah, excellent. That's what I'd hoped; I just wasn't sure if that was an implementation detail, or a guarantee, since the documentation didn't say either way.