Uwaga
Jest to fragment mojej „Co to jest zasada ścisłego aliasowania i dlaczego nas to obchodzi?” napisać
Co to jest ścisłe aliasing?
W C i C ++ aliasing ma związek z typami wyrażeń, przez które mamy dostęp do przechowywanych wartości. Zarówno w C, jak i C ++ standard określa, które typy wyrażeń mogą być używane do aliasu, które typy. Kompilator i optymalizator mogą założyć, że ściśle przestrzegamy zasad aliasingu, stąd termin ścisła zasada aliasingu . Jeśli spróbujemy uzyskać dostęp do wartości przy użyciu niedozwolonego typu, zostanie to zaklasyfikowane jako zachowanie niezdefiniowane ( UB ). Po niezdefiniowanym zachowaniu wszystkie zakłady są wyłączone, wyniki naszego programu nie są już wiarygodne.
Niestety przy surowych naruszeniach aliasingu często uzyskujemy oczekiwane wyniki, pozostawiając możliwość, że przyszła wersja kompilatora z nową optymalizacją zepsuje kod, który naszym zdaniem był prawidłowy. Jest to niepożądane i warto poznać ścisłe zasady aliasingu i unikać ich łamania.
Aby dowiedzieć się więcej o tym, dlaczego nas to obchodzi, omówimy problemy, które pojawiają się w przypadku naruszenia ścisłych reguł aliasingu, pisania na klawiaturze, ponieważ popularne techniki stosowane przy pisaniu na klawiaturze często naruszają ścisłe reguły aliasingu i sposób prawidłowego pisania.
Wstępne przykłady
Spójrzmy na kilka przykładów, a następnie możemy porozmawiać o tym, co mówią standardy, przeanalizować dalsze przykłady, a następnie zobaczyć, jak uniknąć ścisłego aliasingu i złapać naruszenia, które przegapiliśmy. Oto przykład, który nie powinien dziwić ( przykład na żywo ):
int x = 10;
int *ip = &x;
std::cout << *ip << "\n";
*ip = 12;
std::cout << x << "\n";
Mamy int * wskazujące na pamięć zajmowaną przez int i jest to prawidłowe aliasing. Optymalizator musi założyć, że przypisania przez ip mogą zaktualizować wartość zajmowaną przez x .
Następny przykład pokazuje aliasing prowadzący do nieokreślonego zachowania ( przykład na żywo ):
int foo( float *f, int *i ) {
*i = 1;
*f = 0.f;
return *i;
}
int main() {
int x = 0;
std::cout << x << "\n"; // Expect 0
x = foo(reinterpret_cast<float*>(&x), &x);
std::cout << x << "\n"; // Expect 0?
}
W funkcji foo bierzemy int * i liczbę zmiennoprzecinkową * , w tym przykładzie wywołujemy foo i ustawiamy oba parametry tak, aby wskazywały tę samą lokalizację pamięci, która w tym przykładzie zawiera int . Uwaga: reinterpret_cast mówi kompilatorowi, aby traktował wyrażenie tak, jakby miał typ określony przez parametr szablonu. W tym przypadku mówimy, aby traktował wyrażenie & x tak, jakby miał typ float * . Możemy naiwnie oczekiwać, że wynik drugiego cout wyniesie 0, ale przy włączonej optymalizacji przy użyciu -O2 zarówno gcc, jak i clang dają następujący wynik:
0
1
Tego nie można się spodziewać, ale jest to całkowicie poprawne, ponieważ wywołaliśmy niezdefiniowane zachowanie. Element zmiennoprzecinkowy nie może poprawnie aliasu int obiektu . Dlatego optymalizator może przyjąć stałą 1 przechowywaną, gdy dereferencje i będą wartością zwracaną, ponieważ przechowywanie przez f nie może poprawnie wpływać na obiekt int . Podłączenie kodu w Eksploratorze kompilatorów pokazuje, że dokładnie tak się dzieje ( przykład na żywo ):
foo(float*, int*): # @foo(float*, int*)
mov dword ptr [rsi], 1
mov dword ptr [rdi], 0
mov eax, 1
ret
Optymalizator używa analizę aliasów typu (TBAA) zakłada, że 1 zostanie zwrócony i bezpośrednio przenosi wartość stałą do rejestru eax, który przenosi wartość zwracaną. TBAA korzysta z reguł językowych dotyczących typów dozwolonych dla aliasu w celu optymalizacji obciążeń i sklepów. W tym przypadku TBAA wie, że liczba zmiennoprzecinkowa nie może aliasu i int, i optymalizuje obciążenie i .
Teraz do Zestawu Zasad
Co dokładnie mówi standard, że wolno nam, a nie wolno? Standardowy język nie jest prosty, więc dla każdego elementu postaram się podać przykłady kodu, które demonstrują znaczenie.
Co mówi standard C11?
Standard C11 mówi w sekcji 6.5 Wyrażenia, paragraf 7 :
Dostęp do przechowywanej wartości obiektu może mieć tylko wyrażenie wartości, które ma jeden z następujących typów: 88)
- typ zgodny ze skutecznym typem obiektu,
int x = 1;
int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type int which is compatible with int
- kwalifikowana wersja typu zgodna z efektywnym typem obiektu,
int x = 1;
const int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type const int which is compatible with int
- typ, który jest typem podpisanym lub niepodpisanym odpowiadającym efektywnemu typowi obiektu,
int x = 1;
unsigned int *p = (unsigned int*)&x;
printf("%u\n", *p ); // *p gives us an lvalue expression of type unsigned int which corresponds to
// the effective type of the object
gcc / dzyń ma rozszerzenie a także , że pozwala na przypisanie unsigned int * do int * , chociaż nie są one kompatybilne typy.
- typ, który jest typem podpisanym lub niepodpisanym odpowiadającym kwalifikowanej wersji efektywnego typu obiektu,
int x = 1;
const unsigned int *p = (const unsigned int*)&x;
printf("%u\n", *p ); // *p gives us an lvalue expression of type const unsigned int which is a unsigned type
// that corresponds with to a qualified verison of the effective type of the object
- typ agregatu lub związku, który obejmuje jeden z wyżej wymienionych typów wśród jego członków (w tym, rekurencyjnie, członka subagregatu lub zawartego związku), lub
struct foo {
int x;
};
void foobar( struct foo *fp, int *ip ); // struct foo is an aggregate that includes int among its members so it can
// can alias with *ip
foo f;
foobar( &f, &f.x );
- typ postaci.
int x = 65;
char *p = (char *)&x;
printf("%c\n", *p ); // *p gives us an lvalue expression of type char which is a character type.
// The results are not portable due to endianness issues.
Co mówią Craft 17 Draft Standard
Projekt standardu C ++ 17 w sekcji [basic.lval] paragraf 11 mówi:
Jeśli program próbuje uzyskać dostęp do przechowywanej wartości obiektu za pośrednictwem wartości innej niż jeden z następujących typów, zachowanie jest niezdefiniowane: 63
(11.1) - typ dynamiczny obiektu,
void *p = malloc( sizeof(int) ); // We have allocated storage but not started the lifetime of an object
int *ip = new (p) int{0}; // Placement new changes the dynamic type of the object to int
std::cout << *ip << "\n"; // *ip gives us a glvalue expression of type int which matches the dynamic type
// of the allocated object
(11.2) - kwalifikowana do CV wersja dynamicznego typu obiektu,
int x = 1;
const int *cip = &x;
std::cout << *cip << "\n"; // *cip gives us a glvalue expression of type const int which is a cv-qualified
// version of the dynamic type of x
(11.3) - typ podobny (zgodnie z definicją w 7.5) do typu dynamicznego obiektu,
(11.4) - typ, który jest typem podpisanym lub niepodpisanym odpowiadającym typowi dynamicznemu obiektu,
// Both si and ui are signed or unsigned types corresponding to each others dynamic types
// We can see from this godbolt(https://godbolt.org/g/KowGXB) the optimizer assumes aliasing.
signed int foo( signed int &si, unsigned int &ui ) {
si = 1;
ui = 2;
return si;
}
(11.5) - typ, który jest typem podpisanym lub niepodpisanym, odpowiadającym kwalifikowanej do cv wersji typu dynamicznego obiektu,
signed int foo( const signed int &si1, int &si2); // Hard to show this one assumes aliasing
(11.6) - typ agregatu lub związku, który obejmuje jeden z wyżej wymienionych typów wśród jego elementów lub niestatycznych elementów danych (w tym, rekurencyjnie, element lub element danych niestatycznych subagregatu lub zawartego związku),
struct foo {
int x;
};
// Compiler Explorer example(https://godbolt.org/g/z2wJTC) shows aliasing assumption
int foobar( foo &fp, int &ip ) {
fp.x = 1;
ip = 2;
return fp.x;
}
foo f;
foobar( f, f.x );
(11.7) - typ, który jest (prawdopodobnie kwalifikowany do cv) typem klasy podstawowej typu dynamicznego obiektu,
struct foo { int x ; };
struct bar : public foo {};
int foobar( foo &f, bar &b ) {
f.x = 1;
b.x = 2;
return f.x;
}
(11.8) - typ char, unsigned char lub std :: byte.
int foo( std::byte &b, uint32_t &ui ) {
b = static_cast<std::byte>('a');
ui = 0xFFFFFFFF;
return std::to_integer<int>( b ); // b gives us a glvalue expression of type std::byte which can alias
// an object of type uint32_t
}
Warto zauważyć, że znak char nie jest uwzględniony na powyższej liście, jest to zauważalna różnica w stosunku do C, który mówi o typie postaci .
Co to jest Type Punning
Dotarliśmy do tego punktu i możemy się zastanawiać, po co chcieć alias? Zazwyczaj odpowiedź brzmi: pun , często stosowane metody naruszają surowe reguły aliasingu.
Czasami chcemy obejść system typów i zinterpretować obiekt jako inny typ. Nazywa się to pisaniem na klawiaturze , aby ponownie zinterpretować segment pamięci jako inny typ. Pisanie na czcionkach jest przydatne w przypadku zadań, które chcą uzyskać dostęp do podstawowej reprezentacji obiektu w celu przeglądania, transportu lub manipulowania. Typowe obszary, w których spotykamy się ze znakowaniem, to kompilatory, serializacja, kod sieci itp.
Tradycyjnie zostało to osiągnięte poprzez pobranie adresu obiektu, rzutując go na wskaźnik typu, który chcemy ponownie zinterpretować jako, a następnie dostęp do wartości, lub innymi słowy poprzez aliasing. Na przykład:
int x = 1 ;
// In C
float *fp = (float*)&x ; // Not a valid aliasing
// In C++
float *fp = reinterpret_cast<float*>(&x) ; // Not a valid aliasing
printf( "%f\n", *fp ) ;
Jak widzieliśmy wcześniej, nie jest to prawidłowe aliasing, dlatego przywołujemy niezdefiniowane zachowanie. Ale tradycyjnie kompilatory nie korzystały z surowych reguł aliasingu i ten typ kodu zwykle po prostu działał, programiści niestety przyzwyczaili się do robienia tego w ten sposób. Powszechną alternatywną metodą znakowania czcionkami są związki, które są poprawne w C, ale niezdefiniowane zachowanie w C ++ ( patrz przykład na żywo ):
union u1
{
int n;
float f;
} ;
union u1 u;
u.f = 1.0f;
printf( "%d\n”, u.n ); // UB in C++ n is not the active member
Nie jest to poprawne w C ++ i niektórzy uważają, że celem związków jest wyłącznie implementacja typów wariantów i uważają, że używanie związków do znakowania czcionkami jest nadużyciem.
Jak poprawnie wpisujemy Pun?
Standardową metodą znakowania czcionkami zarówno w C, jak i C ++ jest memcpy . To może wydawać się trochę trudne, ale optymalizator powinien rozpoznać użycie memcpy do znakowania i zoptymalizować go i wygenerować rejestr rejestrujący ruch. Na przykład, jeśli wiemy, że int64_t ma ten sam rozmiar co double :
static_assert( sizeof( double ) == sizeof( int64_t ) ); // C++17 does not require a message
możemy użyć memcpy :
void func1( double d ) {
std::int64_t n;
std::memcpy(&n, &d, sizeof d);
//...
Przy wystarczającym poziomie optymalizacji każdy przyzwoity nowoczesny kompilator generuje identyczny kod do wspomnianej wcześniej metody reinterpret_cast lub metody unii dla znakowania typu . Analizując wygenerowany kod, widzimy, że używa tylko rejestracji mov (przykład na żywo Eksploratora kompilatora ).
C ++ 20 i bit_cast
W C ++ 20 możemy uzyskać bit_cast ( implementacja dostępna w linku z propozycji ), co daje prosty i bezpieczny sposób na pisanie na klawiaturze, a także jest możliwe do użycia w kontekście constexpr.
Poniżej znajduje się przykład użycia bit_cast do wpisania pun un unsigned int do float , ( zobacz na żywo ):
std::cout << bit_cast<float>(0x447a0000) << "\n" ; //assuming sizeof(float) == sizeof(unsigned int)
W przypadku, gdy typy Do i Od nie mają tego samego rozmiaru, wymaga od nas użycia struktury pośredniej15. Użyjemy struktury zawierającej tablicę znaków sizeof (unsigned int) (przy założeniu, że 4-bajtowy unsigned int ) jest typu From i unsigned int jako Type To . :
struct uint_chars {
unsigned char arr[sizeof( unsigned int )] = {} ; // Assume sizeof( unsigned int ) == 4
};
// Assume len is a multiple of 4
int bar( unsigned char *p, size_t len ) {
int result = 0;
for( size_t index = 0; index < len; index += sizeof(unsigned int) ) {
uint_chars f;
std::memcpy( f.arr, &p[index], sizeof(unsigned int));
unsigned int result = bit_cast<unsigned int>(f);
result += foo( result );
}
return result ;
}
Szkoda, że potrzebujemy tego typu pośredniego, ale takie jest obecne ograniczenie bit_cast .
Łapanie surowych naruszeń aliasingowych
Nie mamy wielu dobrych narzędzi do przechwytywania ścisłego aliasingu w C ++, narzędzia, które mamy, wychwytują niektóre przypadki ścisłego naruszenia aliasingu oraz niektóre przypadki nieprawidłowego ładowania i przechowywania.
gcc za pomocą flag -fstrict-aliasing i -Wstrict-aliasing może przechwycić niektóre przypadki, chociaż nie bez fałszywych trafień / negatywów. Na przykład następujące przypadki wygenerują ostrzeżenie w gcc ( zobacz na żywo ):
int a = 1;
short j;
float f = 1.f; // Originally not initialized but tis-kernel caught
// it was being accessed w/ an indeterminate value below
printf("%i\n", j = *(reinterpret_cast<short*>(&a)));
printf("%i\n", j = *(reinterpret_cast<int*>(&f)));
chociaż nie złapie tego dodatkowego przypadku ( zobacz na żywo ):
int *p;
p=&a;
printf("%i\n", j = *(reinterpret_cast<short*>(p)));
Chociaż clang pozwala na te flagi, najwyraźniej tak naprawdę nie implementuje ostrzeżeń.
Kolejnym narzędziem, które mamy do dyspozycji, jest ASan, który może wychwycić niedopasowane ładunki i sklepy. Chociaż nie są to bezpośrednio surowe naruszenia aliasingu, są one powszechnym wynikiem ścisłego naruszenia aliasingu. Na przykład następujące przypadki wygenerują błędy środowiska wykonawczego, gdy zostaną zbudowane z clang przy użyciu opcji -fsanitize = adres
int *x = new int[2]; // 8 bytes: [0,7].
int *u = (int*)((char*)x + 6); // regardless of alignment of x this will not be an aligned address
*u = 1; // Access to range [6-9]
printf( "%d\n", *u ); // Access to range [6-9]
Ostatnie narzędzie, które polecę, jest specyficzne dla C ++ i nie jest wyłącznie narzędziem, ale praktyką kodowania, nie zezwalaj na rzutowania w stylu C. Zarówno gcc, jak i clang wygenerują diagnostykę dla rzutów w stylu C przy użyciu -Wold-style-cast . Zmusi to wszystkie niezdefiniowane kalambury do użycia reinterpret_cast, ogólnie reinterpret_cast powinien być flagą do dokładniejszego przeglądu kodu. Łatwiej jest również przeszukać bazę kodu pod kątem reinterpret_cast w celu przeprowadzenia audytu.
W przypadku C mamy już wszystkie narzędzia, a także mamy interpreter tis, analizator statyczny, który wyczerpująco analizuje program dla dużej części języka C. Biorąc pod uwagę wersje C wcześniejszego przykładu, w którym użycie -fstrict-aliasing pomija jeden przypadek ( zobacz na żywo )
int a = 1;
short j;
float f = 1.0 ;
printf("%i\n", j = *((short*)&a));
printf("%i\n", j = *((int*)&f));
int *p;
p=&a;
printf("%i\n", j = *((short*)p));
tis-interpeter jest w stanie złapać wszystkie trzy, poniższy przykład wywołuje tis-kernal jako tis-interpreter (dane wyjściowe są edytowane dla zwięzłości):
./bin/tis-kernel -sa example1.c
...
example1.c:9:[sa] warning: The pointer (short *)(& a) has type short *. It violates strict aliasing
rules by accessing a cell with effective type int.
...
example1.c:10:[sa] warning: The pointer (int *)(& f) has type int *. It violates strict aliasing rules by
accessing a cell with effective type float.
Callstack: main
...
example1.c:15:[sa] warning: The pointer (short *)p has type short *. It violates strict aliasing rules by
accessing a cell with effective type int.
Wreszcie istnieje TySan, który jest obecnie w fazie rozwoju. Ten środek dezynfekujący dodaje informacje o sprawdzaniu typu w segmencie pamięci cienia i sprawdza dostęp, aby sprawdzić, czy naruszają reguły aliasingu. Narzędzie potencjalnie powinno być w stanie wychwycić wszystkie naruszenia aliasingu, ale może mieć duże obciążenie w czasie wykonywania.
cic++faq.