Hinweis
Dies ist ein Auszug aus meinem "Was ist die strikte Aliasing-Regel und warum interessiert es uns?" Aufschreiben.
Was ist striktes Aliasing?
In C und C ++ hat Aliasing damit zu tun, über welche Ausdruckstypen wir auf gespeicherte Werte zugreifen dürfen. Sowohl in C als auch in C ++ gibt der Standard an, welche Ausdruckstypen welche Typen aliasisieren dürfen. Der Compiler und der Optimierer dürfen davon ausgehen, dass wir die Aliasing-Regeln strikt befolgen, daher der Begriff strikte Aliasing-Regel . Wenn wir versuchen, mit einem nicht zulässigen Typ auf einen Wert zuzugreifen, wird dieser als undefiniertes Verhalten ( UB ) klassifiziert . Sobald wir ein undefiniertes Verhalten haben, sind alle Wetten ungültig, und die Ergebnisse unseres Programms sind nicht mehr zuverlässig.
Leider erhalten wir bei strengen Aliasing-Verstößen häufig die erwarteten Ergebnisse, sodass die Möglichkeit besteht, dass eine zukünftige Version eines Compilers mit einer neuen Optimierung den Code beschädigt, den wir für gültig hielten. Dies ist unerwünscht und es ist ein lohnendes Ziel, die strengen Aliasing-Regeln zu verstehen und zu vermeiden, dass sie verletzt werden.
Um mehr darüber zu verstehen, warum es uns wichtig ist, werden wir Probleme diskutieren, die bei Verstößen gegen strenge Aliasing-Regeln auftreten.
Vorläufige Beispiele
Schauen wir uns einige Beispiele an, dann können wir genau darüber sprechen, was die Standards sagen, einige weitere Beispiele untersuchen und dann herausfinden, wie striktes Aliasing vermieden und Verstöße abgefangen werden können, die wir verpasst haben. Hier ist ein Beispiel, das nicht überraschen sollte ( Live-Beispiel ):
int x = 10;
int *ip = &x;
std::cout << *ip << "\n";
*ip = 12;
std::cout << x << "\n";
Wir haben ein int *, das auf den von einem int belegten Speicher verweist, und dies ist ein gültiges Aliasing. Der Optimierer muss davon ausgehen, dass Zuweisungen über IP den von x belegten Wert aktualisieren können .
Das nächste Beispiel zeigt Aliasing, das zu undefiniertem Verhalten führt ( Live-Beispiel ):
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?
}
In der Funktion foo nehmen wir ein int * und ein float * , in diesem Beispiel rufen wir foo auf und setzen beide Parameter so, dass sie auf denselben Speicherort zeigen, der in diesem Beispiel ein int enthält . Beachten Sie, dass der reinterpret_cast den Compiler anweist, den Ausdruck so zu behandeln, als hätte er den durch seinen Vorlagenparameter angegebenen Typ. In diesem Fall weisen wir ihn an, den Ausdruck & x so zu behandeln, als hätte er den Typ float * . Wir können naiv das Ergebnis der zweiten erwarten cout sein 0 , aber mit der Optimierung aktiviert mit -O2 sowohl gcc und Klappern erzeugen folgendes Ergebnis:
0
1
Was nicht zu erwarten ist, aber vollkommen gültig ist, da wir undefiniertes Verhalten aufgerufen haben. Ein Float kann ein int- Objekt nicht gültig aliasen . Daher kann der Optimierer annehmen, dass die Konstante 1, die beim Dereferenzieren von i gespeichert wird, der Rückgabewert ist, da ein Speicher über f ein int- Objekt nicht gültig beeinflussen kann. Das Einstecken des Codes in den Compiler Explorer zeigt, dass genau dies geschieht ( Live-Beispiel ):
foo(float*, int*): # @foo(float*, int*)
mov dword ptr [rsi], 1
mov dword ptr [rdi], 0
mov eax, 1
ret
Der Optimierer, der die typbasierte Alias-Analyse (TBAA) verwendet, geht davon aus, dass 1 zurückgegeben wird, und verschiebt den konstanten Wert direkt in das Register eax, das den Rückgabewert enthält. TBAA verwendet die Sprachregeln für die Alias-Typen, um das Laden und Speichern zu optimieren. In diesem Fall weiß TBAA, dass ein Float nicht alias und int kann und optimiert die Last von i .
Nun zum Regelbuch
Was genau sagt der Standard, dass wir dürfen und was nicht? Die Standardsprache ist nicht einfach, daher werde ich versuchen, für jedes Element Codebeispiele bereitzustellen, die die Bedeutung demonstrieren.
Was sagt der C11-Standard?
Der C11- Standard schreibt in Abschnitt 6.5 Ausdrücke Absatz 7 Folgendes vor :
Auf einen gespeicherten Wert eines Objekts darf nur über einen lvalue-Ausdruck zugegriffen werden, der einen der folgenden Typen aufweist: 88)
- ein Typ, der mit dem effektiven Typ des Objekts kompatibel ist;
int x = 1;
int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type int which is compatible with int
- eine qualifizierte Version eines Typs, der mit dem effektiven Typ des Objekts kompatibel ist;
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
- ein Typ, der der vorzeichenbehaftete oder vorzeichenlose Typ ist, der dem effektiven Typ des Objekts entspricht;
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 / clang hat eine Erweiterung und ermöglicht auch das Zuweisen von int * ohne Vorzeichen zu int * , obwohl es sich nicht um kompatible Typen handelt.
- ein Typ, der der signierte oder nicht signierte Typ ist, der einer qualifizierten Version des effektiven Typs des Objekts entspricht;
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
- ein Aggregat- oder Gewerkschaftstyp, der einen der oben genannten Typen unter seinen Mitgliedern umfasst (einschließlich rekursiv eines Mitglieds eines Unteraggregats oder einer enthaltenen Gewerkschaft), oder
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 );
- ein Zeichentyp.
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.
Was der C ++ 17 Draft Standard sagt
Der C ++ 17-Standardentwurf in Abschnitt [basic.lval] Absatz 11 lautet:
Wenn ein Programm versucht, über einen anderen Wert als einen der folgenden Typen auf den gespeicherten Wert eines Objekts zuzugreifen, ist das Verhalten undefiniert: 63
(11.1) - der dynamische Typ des Objekts,
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) - eine lebenslaufqualifizierte Version des dynamischen Objekttyps,
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) - ein Typ, der dem dynamischen Typ des Objekts ähnlich ist (wie in 7.5 definiert),
(11.4) - Ein Typ, der der vorzeichenbehaftete oder vorzeichenlose Typ ist, der dem dynamischen Typ des Objekts entspricht.
// 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) - ein Typ, der der vorzeichenbehaftete oder vorzeichenlose Typ ist, der einer cv-qualifizierten Version des dynamischen Typs des Objekts entspricht;
signed int foo( const signed int &si1, int &si2); // Hard to show this one assumes aliasing
(11.6) - ein Aggregat- oder Vereinigungstyp, der einen der oben genannten Typen unter seinen Elementen oder nicht statischen Datenelementen enthält (einschließlich rekursiv eines Elements oder eines nicht statischen Datenelements eines Unteraggregats oder einer enthaltenen Vereinigung);
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) - Ein Typ, der ein (möglicherweise lebenslaufqualifizierter) Basisklassentyp des dynamischen Typs des Objekts ist.
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) - ein char-, unsigned char- oder std :: byte-Typ.
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
}
Bemerkenswert ist, dass signiertes Zeichen nicht in der obigen Liste enthalten ist. Dies ist ein bemerkenswerter Unterschied zu C, das einen Zeichentyp angibt .
Was ist Type Punning?
Wir sind an diesem Punkt angelangt und fragen uns vielleicht, warum wir einen Alias haben wollen. Die Antwort ist normalerweise die Eingabe von Wortspiel . Oft verstoßen die verwendeten Methoden gegen strenge Aliasing-Regeln.
Manchmal wollen wir das Typsystem umgehen und ein Objekt als einen anderen Typ interpretieren. Dies wird als Typ-Punning bezeichnet , um ein Speichersegment als einen anderen Typ neu zu interpretieren. Typ Punning ist nützlich für Aufgaben, die Zugriff auf die zugrunde liegende Darstellung eines Objekts zum Anzeigen, Transportieren oder Bearbeiten benötigen . Typische Bereiche, in denen Typ-Punning verwendet wird, sind Compiler, Serialisierung, Netzwerkcode usw.
Traditionell wurde dies erreicht, indem die Adresse des Objekts in einen Zeiger des Typs umgewandelt wurde, als den wir es neu interpretieren möchten, und dann auf den Wert zugegriffen wurde, oder mit anderen Worten durch Aliasing. Zum Beispiel:
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 ) ;
Wie wir bereits gesehen haben, ist dies kein gültiges Aliasing, daher rufen wir undefiniertes Verhalten auf. Aber traditionell nutzten Compiler strenge Aliasing-Regeln nicht und diese Art von Code funktionierte normalerweise nur. Entwickler haben sich leider daran gewöhnt, Dinge auf diese Weise zu tun. Eine übliche alternative Methode zum Typ-Punning sind Gewerkschaften, die in C gültig sind, in C ++ jedoch undefiniertes Verhalten ( siehe Live-Beispiel ):
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
Dies ist in C ++ nicht gültig und einige betrachten den Zweck von Gewerkschaften ausschließlich als Implementierung von Variantentypen und halten die Verwendung von Gewerkschaften für Typ-Punning für einen Missbrauch.
Wie geben wir Pun richtig ein?
Die Standardmethode für Typ-Punning in C und C ++ ist memcpy . Dies mag ein wenig hartnäckig erscheinen, aber der Optimierer sollte die Verwendung von memcpy für das Typ-Punning erkennen und es wegoptimieren und ein Register generieren, um die Bewegung zu registrieren. Wenn wir beispielsweise wissen, dass int64_t dieselbe Größe wie double hat :
static_assert( sizeof( double ) == sizeof( int64_t ) ); // C++17 does not require a message
wir können memcpy verwenden :
void func1( double d ) {
std::int64_t n;
std::memcpy(&n, &d, sizeof d);
//...
Bei einer ausreichenden Optimierungsstufe generiert jeder anständige moderne Compiler identischen Code wie die zuvor erwähnte reinterpret_cast- Methode oder Union- Methode für Typ-Punning . Wenn wir den generierten Code untersuchen, sehen wir, dass nur register mov verwendet wird ( Live Compiler Explorer-Beispiel ).
C ++ 20 und bit_cast
In C ++ 20 erhalten wir möglicherweise bit_cast ( Implementierung im Link vom Vorschlag verfügbar ), das eine einfache und sichere Möglichkeit zum Eingeben von Wortspielen bietet und in einem constexpr-Kontext verwendet werden kann.
Das folgende Beispiel zeigt, wie Sie mit bit_cast pun ein vorzeichenloses int eingeben, um zu schweben ( siehe live ):
std::cout << bit_cast<float>(0x447a0000) << "\n" ; //assuming sizeof(float) == sizeof(unsigned int)
In dem Fall , wo zu und von Arten nicht die gleiche Größe hat, bedarf es uns einen Zwischen struct15 zu verwenden. Wir werden eine Struktur verwenden, die ein Zeichenarray sizeof (unsigned int) enthält ( vorausgesetzt, 4 Byte unsigned int ), um den From- Typ und unsigned int als To- Typ zu sein :.
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 ;
}
Es ist bedauerlich, dass wir diesen Zwischentyp benötigen, aber das ist die aktuelle Einschränkung von bit_cast .
Auffangen strenger Aliasing-Verstöße
Wir haben nicht viele gute Tools zum Abfangen von striktem Aliasing in C ++. Die Tools, die wir haben, werden einige Fälle von strengen Aliasing-Verstößen und einige Fälle von falsch ausgerichteten Ladevorgängen und Speichern abfangen.
gcc mit dem Flag -fstrict-aliasing und -Wstrict-aliasing kann einige Fälle abfangen, wenn auch nicht ohne falsch positive / negative Ergebnisse . In den folgenden Fällen wird beispielsweise eine Warnung in gcc generiert ( siehe live ):
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)));
obwohl es diesen zusätzlichen Fall nicht erfassen wird ( sehen Sie es live ):
int *p;
p=&a;
printf("%i\n", j = *(reinterpret_cast<short*>(p)));
Obwohl clang diese Flags zulässt, werden die Warnungen anscheinend nicht implementiert.
Ein weiteres Tool, das uns zur Verfügung steht, ist ASan, mit dem falsch ausgerichtete Lasten und Speicher aufgefangen werden können. Obwohl dies keine direkten strengen Aliasing-Verstöße sind, sind sie ein häufiges Ergebnis strenger Aliasing-Verstöße. In den folgenden Fällen werden beispielsweise Laufzeitfehler generiert, wenn mit clang unter Verwendung von -fsanitize = address erstellt wird
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]
Das letzte Tool, das ich empfehlen werde, ist C ++ - spezifisch und nicht ausschließlich ein Tool, sondern eine Codierungspraxis. Lassen Sie keine Casts im C-Stil zu. Sowohl gcc als auch clang erstellen eine Diagnose für Casts im C-Stil unter Verwendung von Cast im -Wold-Stil . Dadurch werden alle undefinierten Wortspiele gezwungen, reinterpret_cast zu verwenden. Im Allgemeinen sollte reinterpret_cast ein Flag für eine genauere Codeüberprüfung sein. Es ist auch einfacher, Ihre Codebasis nach reinterpret_cast zu durchsuchen, um eine Prüfung durchzuführen.
Für C haben wir alle Tools bereits behandelt und wir haben auch tis-interpreter, einen statischen Analysator, der ein Programm für eine große Teilmenge der C-Sprache ausführlich analysiert. Bei einer C-Version des früheren Beispiels, bei der bei Verwendung von -fstrict-aliasing ein Fall übersehen wird ( siehe live )
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 kann alle drei abfangen. Im folgenden Beispiel wird tis-kernal als tis-Interpreter aufgerufen (die Ausgabe wird der Kürze halber bearbeitet):
./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.
Schließlich gibt es TySan, das derzeit entwickelt wird. Dieses Desinfektionsprogramm fügt Informationen zur Typprüfung in ein Schattenspeichersegment ein und überprüft die Zugriffe, um festzustellen, ob sie gegen Aliasing-Regeln verstoßen. Das Tool sollte möglicherweise in der Lage sein, alle Aliasing-Verstöße zu erkennen, hat jedoch möglicherweise einen hohen Laufzeitaufwand.
cundc++faq.