¿Por qué un campo de 8 bits tiene endianness?

Consulte la definición de encabezado TCP en /netinet/tcp.h:

struct tcphdr
  {
    u_int16_t th_sport;         /* source port */
    u_int16_t th_dport;         /* destination port */
    tcp_seq th_seq;             /* sequence number */
    tcp_seq th_ack;             /* acknowledgement number */
#  if __BYTE_ORDER == __LITTLE_ENDIAN
    u_int8_t th_x2:4;           /* (unused) */
    u_int8_t th_off:4;          /* data offset */
#  endif
#  if __BYTE_ORDER == __BIG_ENDIAN
    u_int8_t th_off:4;          /* data offset */
    u_int8_t th_x2:4;           /* (unused) */
#  endif
    u_int8_t th_flags;
#  define TH_FIN        0x01
#  define TH_SYN        0x02
#  define TH_RST        0x04
#  define TH_PUSH       0x08
#  define TH_ACK        0x10
#  define TH_URG        0x20
    u_int16_t th_win;           /* window */
    u_int16_t th_sum;           /* checksum */
    u_int16_t th_urp;           /* urgent pointer */
};

¿Por qué el campo de 8 bits tiene un orden diferente en endianness? Pensé que solo los campos de 16 bits y 32 bits importaban con el orden de los bytes, y que podías convertir entre endian con ntohs y ntohl, respectivamente. ¿Cuál sería la función para manejar cosas de 8 bits? Si no hay ninguno, parece que un TCP que usa este encabezado en una máquina little endian no funcionaría con un TCP en una máquina big endian.

Hay dos tipos de orden. Uno es el orden de los bytes, el otro es el orden de los campos de bits. No existe un orden estándar sobre el orden de los campos de bits en lenguaje C. Depende del compilador. Normalmente, el orden de los campos de bits se invierte entre big y little endian.

Esto depende del compilador y no es portátil. La forma en que se ordenan los campos de bits depende de la implementación, aquí sería mucho mejor usar un campo de 8 bits y un desplazamiento/máscara para obtener los subcampos.

Es posible que en esta máquina el endianess también se refiera al orden de bits así como al orden de bytes. este articulo de wikipedia menciona que este es a veces el caso.

Tengo entendido que el ordenamiento de bits y el endianismo son generalmente dos cosas diferentes. Las estructuras con campos de bits generalmente no son portátiles entre compiladores/arquitecturas. A veces, ifdefs se puede usar para admitir diferentes órdenes de bits. En este caso, el endianness es realmente irrelevante y debería ser un ifdef sobre el orden de los bits. La suposición de que algunas endianesses tienen un cierto orden de bits puede ser cierta en algunos casos.

Mi lectura del comentario es que los dos campos de un byte juntos se interpretan como un valor de dos bytes (o lo eran, parece que un byte no se usa de todos modos). En lugar de declarar un valor de dos bytes, declaran dos valores de un byte pero invierten el orden de declaración dependiendo de la endianidad.

Puede ser útil saber que este código solo se ejecuta si “# ifdef __FAVOR_BSD”. Es de /usr/include/netinet/tcp.h

# ifdef __FAVOR_BSD
typedef u_int32_t tcp_seq;
/*
 * TCP header.
 * Per RFC 793, September, 1981.
 */
struct tcphdr