字節序如何影響結構中的位域定義？

Question

使用 iphdr 作為第一個示例：

struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
    __u8    ihl:4,
            version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
    __u8    version:4,
            ihl:4;
#else
#error  "Please fix <asm/byteorder.h>"
#endif

    /* other fields are emitted. */
};

我的問題 1，據我所知，字節序僅在處理多字節時影響，換句話說，如果只有 1 個字節，則沒有“位順序”這樣的事情。 在上面的定義中，ihl+version= 8 bits = 1 byte，ihl 和 version 駐留在一個字節中，為什么我們要關心 ihl 和 version 的字節序和逆序呢？

如果“位順序”是一個問題，我的問題 2 是為什么另一個 struct ip_options 不關心字節序？

struct ip_options {
    __be32      faddr;
    __be32      nexthop;
    unsigned char   optlen;
    unsigned char   srr;
    unsigned char   rr;
    unsigned char   ts;
    unsigned char   is_strictroute:1,  // why this byte doesn't care endianness?
                    srr_is_hit:1,
                    is_changed:1,
                    rr_needaddr:1,
                    ts_needtime:1,
                    ts_needaddr:1;
    unsigned char   router_alert;
    unsigned char   cipso;
    unsigned char   __pad2;
    unsigned char   __data[0];
};

Answer 1

C 不需要字節順序來指示__u8 ihl:4使用 4 MSBits 還是 4 LSBits。

為什么我們要關心 ihl 和 version 的字節序和逆序？

原作者可能想在一個硬件地址上疊加struct iphdr ，玩玩union魔法或者實現某種串口通信順序。

該方法的可移植性不高，但可能已經滿足了最初的有限需求。

如果“位順序”是一個問題，我的問題 2 是為什么另一個 struct ip_options 不關心字節序？

這是一種無常。

處理超出標頭的字節序可能無關緊要。 標頭類型struct iphdr可能需要與字節序無關的編碼，但是一旦分配了這些成員，剩余的代碼就會相應地進行解釋。 如果除標頭之外的所有標頭都具有#if defined(__LITTLE_ENDIAN_BITFIELD)則可能是這種情況。

.tiff做了這樣的事情。

Answer 2

C 標准幾乎完全未指定位域實現，因此無法確定。

根據6.7.2.1 結構和聯合說明符，第 11 段：

一個實現可以分配任何足夠大的可尋址存儲單元來保存一個位字段。 如果剩余足夠的空間，緊跟在結構中另一個位域之后的位域應被打包到同一單元的相鄰位中。 如果剩余空間不足，則不適合的位字段是否放入下一個單元或與相鄰單元重疊是實現定義的。 單元內位域的分配順序（高階到低階或低階到高階）是實現定義的。 可尋址存儲單元的對齊方式未指定。

實際上沒有可移植的方式在 C 中使用位域。唯一指定的是“如果還有足夠的空間”部分。 但是，即使該空間的大小也完全懸而未決，因為“[a]n 實現可能會分配任何足夠大的可尋址存儲單元以容納一個位字段。”