¿Por qué la endianidad de bit es un problema en bitfields?

Hasta donde yo entiendo, los bitfields son construcciones puramente compiladoras

Y eso es parte del problema. Si el uso de los campos de bits se restringiera a lo que el compilador 'poseía', entonces cómo el compilador empacó los bits o los ordenó no sería de preocupación para nadie.

Sin embargo, los campos de bits probablemente se usan mucho más a menudo para modelar construcciones que son externas a los registros de hardware de dominio del compilador, el protocolo' wire ' para comunicaciones o el archivo diseño de formato. Estas cosas tienen requisitos estrictos de cómo los bits tienen que ser establecidos, y el uso de campos de bits para modelarlos significa que usted tiene que confiar en la implementación definida y-peor aún-el comportamiento no especificado de cómo el compilador diseñará el campo de bits.

En resumen, los campos de bits no se especifican lo suficientemente bien como para hacerlos útiles para las situaciones para las que parecen ser más utilizados.

ISO / IEC 9899: 6.7.2.1 / 10

Una implementación puede asignar cualquier unidad de almacenamiento direccionable lo suficientemente grande para mantener un poco de campo. Si hay suficiente espacio sigue siendo, un poco de campo que inmediatamente sigue otro campo de bits en un la estructura se embalará en bits adyacentes de la misma unidad. Si sigue siendo insuficiente el espacio, ya sea bit-campo que no encaja se pone en la siguiente unidad o se superpone adyacente unidades está definida por la implementación. El orden de asignación de campos de bits dentro de una unidad (de orden alto a orden bajo o de orden bajo a orden alto) es implementación-definida. Alineacion de la unidad de almacenamiento direccionable es sin especificar.

Es más seguro usar operaciones de desplazamiento de bits en lugar de hacer suposiciones sobre el orden o la alineación de campos de bits cuando se intenta escribir código portátil, independientemente de la endianidad del sistema o la bitness.

Véase también EXP11-C. No aplicar operadores que esperan un tipo a los datos de un tipo.

Los accesos a los campos de bits se implementan en términos de operaciones sobre el tipo subyacente. En el ejemplo, unsigned int. Así que si tienes algo como:

struct x {
    unsigned int a : 4;
    unsigned int b : 8;
    unsigned int c : 4;
};

Cuando accede al campo b, el compilador accede a un unsigned int completo y luego cambia y enmascara el rango de bits apropiado. (Bueno, no tiene que, pero podemos pretender que lo hace.)

En big endian, el diseño será algo como esto (primero el bit más significativo):

AAAABBBB BBBBCCCC

En little endian, el diseño será así:

BBBBAAAA CCCCBBBB

Si quieres acceder al diseño de big endian desde little endian o viceversa, tendrás que hacer un trabajo extra. Este aumento en la portabilidad tiene una penalización en el rendimiento, y dado que el diseño de la estructura ya no es portable, los implementadores de lenguaje optaron por la versión más rápida.

Esto hace muchas suposiciones. También tenga en cuenta que sizeof(struct x) == 4 en la mayoría de las plataformas.

Los campos de bits se almacenarán en un orden diferente dependiendo de la endianidad de la máquina, esto puede no importar en algunos casos, pero en otros puede importar. Digamos, por ejemplo, que su estructura ParsedInt representa banderas en un paquete enviado a través de una red, una máquina little endian y una máquina big endian leen esas banderas en un orden diferente del byte transmitido, lo que obviamente es un problema.

Para hacer eco de los puntos más destacados: Si está utilizando esto en una sola plataforma de compilador/HW como una construcción solo de software, entonces la endianidad no será un problema. Si está utilizando código o datos en varias plataformas O necesita coincidir con diseños de bits de hardware, entonces ES un problema. Y un lote de software profesional es multiplataforma, por lo tanto, tiene que preocuparse.

Aquí está el ejemplo más simple: Tengo código que almacena números en formato binario al disco. Si no escribo y lea estos datos al disco yo mismo explícitamente byte por byte, entonces no será el mismo valor si se lee desde un sistema endian opuesto.

Ejemplo concreto:

Int16_t s = 4096; // un número firmado de 16 bits...

Digamos que mi programa se envía con algunos datos en el disco que quiero leer. Digamos que quiero cargarlo como 4096 en este caso...

Fread((void*)&s, 2, fp); // lectura del disco como binario...

Aquí lo leo como un valor de 16 bits, no como explícito byte. Esto significa que si mi sistema coincide con el peso se almacena en el disco, me da 4096, y si no, tengo 16 !!!!!

Así que el uso más común de la endianidad es cargar números binarios a granel, y luego hacer un bswap si no coincide. En el pasado, almacenábamos datos en el disco como big endian porque Intel era el hombre extraño y proporcionaba instrucciones de alta velocidad para intercambiar los bytes. Hoy en día, Intel es tan común que a menudo hace que Little Endian sea el predeterminado y se intercambie cuando está en un big endian sistema.

Un enfoque más lento, pero neutro endiano es hacer TODAS las E / S por bytes, es decir:

Uint_8 ubyte; int_8 sbyte; int16_t s; / / leer s en endian neutral way

/ / Vamos a elegir little endian como nuestro orden de bytes elegido:

Fread ((void*)&ubyte, 1, fp); / / Solo se lee 1 byte a la vez fread ((void*) & sbyte, 1, fp); // Solo lee 1 byte a la vez

// Reconstruir s

S = ubyte / (sByte

Tenga en cuenta que esto es idéntico al código en el que escribiría haga un intercambio de endian, pero ya no es necesario comprobar la endianidad. Y puede usar macros para que esto sea menos doloroso.

He utilizado el ejemplo de los datos almacenados utilizados por un programa. La otra aplicación principal mencionada es para escribir registros de hardware, donde esos registros tienen un orden absoluto. Un lugar MUY COMÚN que esto surge es con gráficos. Obtener la endianness mal y sus canales de color rojo y azul se invierten! Una vez más, el problema es uno de portabilidad-simplemente podría adaptarse a una plataforma de hardware y tarjeta gráfica dada, pero si desea que su mismo código funcione en diferentes máquinas, debe probar.

Aquí está una prueba clásica:

Typedef union { uint_16 s; uint_8 b[2];} EndianTest_t;

EndianTest_t test = 4096;

If (test.b[0] == 12) printf ("Big Endian Detected!\n");

Tenga en cuenta que los problemas de campo de bits también existen, pero son ortogonales a los problemas de endianidad.