Czy atrybut gcc ((packed)) / # pragma pack jest niebezpieczny?

Jak wspomniałem powyżej, nie bierz wskaźnika do członka struktury, która jest spakowana. To po prostu igraszki z ogniem. Kiedy mówisz __attribute__((__packed__)) lub #pragma pack(1), tak naprawdę mówisz: "Hej gcc, naprawdę wiem, co robię."Kiedy okazuje się, że nie, nie można słusznie winić kompilatora.

Być może możemy obwinić kompilator za jego samozadowolenie. Chociaż gcc ma opcję -Wcast-align, nie jest ona domyślnie włączona ani przez -Wall ani -Wextra. Wynika to najwyraźniej z gcc Programiści uważający ten typ kodu za martwy mózg "obrzydliwość " niegodny adresowania-zrozumiała pogarda, ale to nie pomaga, gdy niedoświadczony programista wpada w niego.

Rozważ co następuje:

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;

Tutaj typ a jest strukturą spakowaną (jak zdefiniowano powyżej). Podobnie, b jest wskaźnikiem do spakowanej struktury. Typ wyrażenia a.i jest (zasadniczo) wartością int l-value z wyrównaniem 1 bajtów. c i d oba są normalne ints. podczas odczytu a.i kompilator generuje kod dla dostępu bez przypisania. Kiedy czytasz b->i, b'typ s nadal wie, że jest spakowany, więc nie ma problemu. e jest wskaźnikiem do jednobajtowej int wyrównanej, więc kompilator wie, jak również poprawnie dereferować. Ale kiedy wykonujesz przypisanie f = &a.i, przechowujesz wartość niepalowanego wskaźnika int w wyrównanej zmiennej wskaźnika int -- to miejsce, w którym się pomyliłeś. I zgadzam się, gcc powinno mieć to warning enabled by default (not even in -Wall or -Wextra).

Jest to całkowicie bezpieczne, o ile zawsze uzyskujesz dostęp do wartości za pośrednictwem struktury za pomocą notacji . (kropka) lub ->.

To, co Nie jest bezpieczne, to wzięcie wskaźnika niepodpisanych danych, a następnie uzyskanie do nich dostępu bez brania tego pod uwagę.

Również, nawet jeśli każdy element struktury jest znany jako niepodpisany, jest znany jako niepodpisany w określony sposób , więc struktura jako całość musi być wyrównana zgodnie z oczekiwaniami kompilatora, inaczej będą problemy (na niektórych przykładach platformy, lub w przyszłości, jeśli zostanie wymyślony nowy sposób optymalizacji niezaleganych dostępów).

Używanie tego atrybutu jest zdecydowanie niebezpieczne.

Jedną z szczególnych rzeczy, które łamie, jest zdolność union, która zawiera dwie lub więcej struktur do zapisu jednego członu i odczytu drugiego, jeśli struktury mają wspólną początkową sekwencję członów. Sekcja 6.5.2.3 normy C11 stwierdza:

6 w celu uproszczenia korzystania ze związków: jeśli związek zawiera kilka struktur, które dzielą wspólną Sekwencja początkowa (patrz niżej), a jeśli celem Unii obecnie zawiera jedną z tych struktur, dozwolone jest aby sprawdzić wspólną początkową część dowolnego z nich w dowolnym miejscu, które a widoczna jest deklaracja wypełnionego typu Unii. Tw o struktury mają wspólną sekwencję początkową, jeśli odpowiada Członkowie mają kompatybilne typy (i, dla pól bitowych, te same szerokości) dla sekwencji jednego lub więcej członów początkowych.

...

9 Przykład 3 Poniżej znajduje się poprawny fragment:

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)
/*
...
*/

Kiedy __attribute__((packed)) jest wprowadzony, łamie to. Poniższy przykład został uruchomiony na Ubuntu 16.04 x64 przy użyciu gcc 5.4.0 z wyłączonymi optymalizacjami:

#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;
}

Wyjście:

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

Mimo że struct s1 i struct s2 mają "wspólną sekwencję początkową", opakowanie zastosowane do pierwszego oznacza, że odpowiednie elementy nie żyją w tym samym offsecie bajtowym. Wynik jest taki, że wartość zapisana do elementu x.b nie jest taka sama jak wartość odczytywana z member y.b, mimo że standard mówi, że powinny być takie same.

(poniższy przykład jest bardzo sztucznym przykładem do zilustrowania.) Jednym z głównych zastosowań spakowanych struktur jest tam, gdzie masz strumień danych (powiedzmy 256 bajtów), do którego chcesz podać znaczenie. Jeśli wezmę mniejszy przykład, załóżmy, że mam program uruchomiony na moim Arduino, który wysyła szeregowo pakiet 16 bajtów, które mają następujące znaczenie:

0: message type (1 byte)
1: target address, MSB
2: target address, LSB
3: data (chars)
...
F: checksum (1 byte)

Wtedy mogę zadeklarować coś w rodzaju

typedef struct {
  uint8_t msgType;
  uint16_t targetAddr; // may have to bswap
  uint8_t data[12];
  uint8_t checksum;
} __attribute__((packed)) myStruct;

I wtedy mogę odwołać się do bajtów targetAddr poprzez aStruct.targetAddr niż majstrować przy arytmetyce wskaźników.

Teraz, gdy dzieje się wyrównanie, pobranie wskaźnika void* w pamięci do odebranych danych i wysłanie go do myStruct* nie zadziała chyba że kompilator traktuje strukturę jako spakowaną (tzn. przechowuje dane w podanej kolejności i używa dokładnie 16 bajtów dla tego przykładu). Istnieją kary wydajnościowe za niezaliczone odczyty, więc używanie spakowanych struktur danych, z którymi aktywnie współpracuje Twój program, niekoniecznie jest dobrym pomysłem. Ale gdy program jest dostarczany z listą bajtów, spakowane struktury ułatwiają pisanie programów, które mają dostęp do zawartości.

W przeciwnym razie skończysz używając C++ i pisząc klasę z metodami accessor i takimi tam, które robią arytmetykę wskaźników za kulisami. Krótko mówiąc, spakowane struktury służą do efektywnego radzenia sobie z spakowanymi danymi, a spakowane dane mogą być tym, z czym dany jest program do pracy. W większości przypadków kod powinien odczytywać wartości ze struktury, pracować z nimi i pisać wróciły, kiedy skończyły. Wszystko inne powinno być wykonane poza spakowaną strukturą. Częścią problemu są rzeczy niskiego poziomu, które C próbuje ukryć przed programistą, i skoki obręczy, które są potrzebne, jeśli takie rzeczy naprawdę mają dla programisty znaczenie. (Prawie potrzebujesz innego "układu danych" w języku, aby można było powiedzieć "to coś ma 48 bajtów, foo odnosi się do danych 13 bajtów i powinno być interpretowane w ten sposób"; i oddzielny strukturalny konstrukt danych, gdzie mówisz " chcę struktura zawierająca dwa inty, o nazwie alice i bob, oraz float o nazwie carol, i nie obchodzi mnie jak to zaimplementujesz ' -- w C oba te przypadki użycia są przypisane do struktury struct.)