¿El paquete __attribute__((packed)) / #pragma de gcc no es seguro?

En C, el compilador distribuirá los miembros de una estructura en el orden en que se declaran, con posibles bytes de relleno insertados entre los miembros, o después del último miembro, para garantizar que cada miembro esté alineado correctamente.

gcc proporciona una extensión de lenguaje, __attribute__((packed))que le indica al compilador que no inserte relleno, lo que permite que los miembros de la estructura queden desalineados. Por ejemplo, si el sistema normalmente requiere que todos intlos objetos tengan una alineación de 4 bytes, __attribute__((packed))puede provocar intque los miembros de la estructura se asignen en desplazamientos impares.

Citando la documentación de gcc:

El atributo "empaquetado" especifica que una variable o campo de estructura debe tener la alineación más pequeña posible: un byte para una variable y un bit para un campo, a menos que especifique un valor mayor con el atributo "alineado".

Obviamente, el uso de esta extensión puede dar como resultado menores requisitos de datos pero un código más lento, ya que el compilador debe (en algunas plataformas) generar código para acceder a un miembro desalineado byte a byte.

Pero, ¿hay algún caso en el que esto no sea seguro? ¿El compilador siempre genera código correcto (aunque más lento) para acceder a miembros desalineados de estructuras empaquetadas? ¿Es siquiera posible que lo haga en todos los casos?

Dec 20 '11 05:12 Keith Thompson

Como dijo ams anteriormente, no tome un puntero a un miembro de una estructura que esté empaquetada. Esto es simplemente jugar con fuego. Cuando dices __attribute__((__packed__))o #pragma pack(1), lo que realmente estás diciendo es "Hola, gcc, realmente sé lo que estoy haciendo". Cuando resulta que no es así, no se puede culpar al compilador.

Sin embargo, quizás podamos culpar al compilador por su complacencia. Si bien gcc tiene una -Wcast-alignopción, no está habilitada de forma predeterminada ni con -Wallo -Wextra. Aparentemente, esto se debe a que los desarrolladores de gcc consideran que este tipo de código es una " abominación " con muerte cerebral que no merece ser abordada: desdén comprensible, pero no ayuda cuando un programador sin experiencia se topa con él.

Considera lo siguiente:

struct  __attribute__((__packed__)) my_struct {
    char c;
    int i;
};

struct my_struct a = {'a', 123};
struct my_struct *b = &a;
int c = a.i;
int d = b->i;
int *e __attribute__((aligned(1))) = &a.i;
int *f = &a.i;

Aquí, el tipo de aes una estructura empaquetada (como se definió anteriormente). De manera similar, bes un puntero a una estructura empaquetada. El tipo de expresión a.ies (básicamente) un valor int l con alineación de 1 byte. cy dambos son normales ints. Al leer a.i, el compilador genera código para acceso no alineado. Cuando lees b->i, bel tipo todavía sabe que está lleno, así que tampoco hay problema. ees un puntero a un int alineado de un byte, por lo que el compilador también sabe cómo desreferenciarlo correctamente. Pero cuando realiza la asignación f = &a.i, está almacenando el valor de un puntero int no alineado en una variable de puntero int alineado; ahí es donde salió mal. Y estoy de acuerdo, gcc debería tener esta advertencia habilitada de forma predeterminada (ni siquiera en -Wallo -Wextra).

Apr 08 '2013 04:04 Daniel Santos

Es perfectamente seguro siempre que siempre acceda a los valores a través de la estructura mediante la notación .(punto) o ->.

Lo que no es seguro es tomar el puntero de datos no alineados y luego acceder a ellos sin tenerlo en cuenta.

Además, aunque se sabe que cada elemento de la estructura está desalineado, se sabe que está desalineado de una manera particular , por lo que la estructura en su conjunto debe estar alineada como espera el compilador o habrá problemas (en algunas plataformas, o en el futuro si se inventa una nueva forma de optimizar los accesos no alineados).

Dec 20 '2011 10:12 ams

Usar este atributo definitivamente no es seguro.

Una cosa particular que rompe es la capacidad de un unionque contiene dos o más estructuras de escribir un miembro y leer otro si las estructuras tienen una secuencia inicial común de miembros. La sección 6.5.2.3 de la norma C11 establece:

6 Se ofrece una garantía especial para simplificar el uso de uniones: si una unión contiene varias estructuras que comparten una secuencia inicial común (ver más abajo), y si el objeto de unión actualmente contiene una de estas estructuras, se permite inspeccionar la parte inicial común de cualquiera de ellos en cualquier lugar donde sea visible una declaración del tipo de unión completada. Dos estructuras comparten una secuencia inicial común si los miembros correspondientes tienen tipos compatibles (y, para campos de bits, los mismos anchos) para una secuencia de uno o más miembros iniciales.

...

9 EJEMPLO 3 El siguiente es un fragmento válido:

union {
    struct {
        int    alltypes;
    }n;
    struct {
        int    type;
        int    intnode;
    } ni;
    struct {
        int    type;
        double doublenode;
    } nf;
}u;
u.nf.type = 1;
u.nf.doublenode = 3.14;
/*
...
*/
if (u.n.alltypes == 1)
if (sin(u.nf.doublenode) == 0.0)
/*
...
*/

Cuando __attribute__((packed))se introduce, se rompe esto. El siguiente ejemplo se ejecutó en Ubuntu 16.04 x64 usando gcc 5.4.0 con las optimizaciones deshabilitadas:

#include <stdio.h>
#include <stdlib.h>

struct s1
{
    short a;
    int b;
} __attribute__((packed));

struct s2
{
    short a;
    int b;
};

union su {
    struct s1 x;
    struct s2 y;
};

int main()
{
    union su s;
    s.x.a = 0x1234;
    s.x.b = 0x56789abc;

    printf("sizeof s1 = %zu, sizeof s2 = %zu\n", sizeof(struct s1), sizeof(struct s2));
    printf("s.y.a=%hx, s.y.b=%x\n", s.y.a, s.y.b);
    return 0;
}

Producción:

sizeof s1 = 6, sizeof s2 = 8
s.y.a=1234, s.y.b=5678

Aunque struct s1y struct s2tienen una "secuencia inicial común", el empaquetado aplicado al primero significa que los miembros correspondientes no viven en el mismo desplazamiento de bytes. El resultado es que el valor escrito en member x.bno es el mismo que el valor leído en member y.b, aunque el estándar dice que deberían ser iguales.

Apr 02 '2019 18:04 dbush