Bit field order changes depending on endianness. Is this intentional?

[Lezvix]

I noticed that when using bitX() fields, the generated code changes the bit order depending on the selected endianness.

With .endianness("little"):

vars.b1 = $tmp0 >> 0 & 0x1;
vars.b2 = $tmp0 >> 1 & 0x1;
vars.b3 = $tmp0 >> 2 & 0x1;
vars.b4 = $tmp0 >> 3 & 0x1;

With .endianness("big"):

vars.b1 = $tmp0 >> 7 & 0x1;
vars.b2 = $tmp0 >> 6 & 0x1;
vars.b3 = $tmp0 >> 5 & 0x1;
vars.b4 = $tmp0 >> 4 & 0x1;

Since bit fields are extracted from a single byte (getUint8), and endianness typically affects only multi-byte values (e.g., uint16, uint32), I would not expect bit order within a byte to change.

Is this behavior intentional?
Why does endianness affect the order of bits inside a single byte?

[keichi]

Yes, this is intentional. It was an early design choice (commit 545ed29).

The rationale is that endianness is extended to the bit level: in big-endian mode, bit fields are extracted from MSB to LSB (matching the convention used by network protocol specifications like IP/TCP headers), while in little-endian mode, they are extracted from LSB to MSB.

You're right that endianness typically only affects multi-byte values at the byte level. However, when parsing bit fields, there needs to be a defined order for extracting bits, and tying it to the endianness setting provides a consistent convention.

If you need big-endian bit ordering regardless of byte-level endianness, you can parse the bit fields in a separate Parser with .endianness("big") and use .nest() to
embed it:

  const bitFields = new Parser()
    .endianness("big")
    .bit1("b1")
    .bit1("b2")
    .bit1("b3")
    .bit1("b4");

  const parser = new Parser()
    .endianness("little")
    .nest("flags", { type: bitFields })
    .uint16("value");

[Lezvix]

Thank you for the detailed explanation, this approach really makes sense!

I think it's worth mentioning in the API description of the 'endianness' method that it also affects the bit-order, to avoid confusion in the future.

[keichi]

Thanks for the suggestion! I've documented this in #290.