Remarque
Ceci est extrait de mon "Qu'est-ce que la règle de repliement strict et pourquoi nous en soucions-nous?"rédiger.
Qu'est-ce qu'un aliasing strict?
En C et C ++, l'aliasing a à voir avec quels types d'expression nous sommes autorisés à accéder aux valeurs stockées. En C et C ++, la norme spécifie quels types d'expression sont autorisés à alias quels types. Le compilateur et l'optimiseur sont autorisés à supposer que nous suivons strictement les règles d'alias, d'où le terme de règle d'alias stricte . Si nous tentons d'accéder à une valeur en utilisant un type non autorisé, elle est classée comme comportement non défini ( UB ). Une fois que nous avons un comportement indéfini, tous les paris sont désactivés, les résultats de notre programme ne sont plus fiables.
Malheureusement, avec des violations d'alias strictes, nous obtiendrons souvent les résultats escomptés, laissant la possibilité qu'une future version d'un compilateur avec une nouvelle optimisation casse le code que nous pensions être valide. Ce n'est pas souhaitable et c'est un objectif valable de comprendre les règles strictes d'alias et comment éviter de les violer.
Pour mieux comprendre pourquoi nous nous soucions, nous discuterons des problèmes qui surviennent lors de la violation de règles d'aliasing strictes, de la punition de type car les techniques courantes utilisées dans la punition de type violent souvent les règles d'aliasing strictes et comment taper correctement pun.
Exemples préliminaires
Regardons quelques exemples, puis nous pourrons parler exactement de ce que disent les normes, examiner d'autres exemples et voir comment éviter l'aliasing strict et les violations de capture que nous avons manquées. Voici un exemple qui ne devrait pas surprendre ( exemple en direct ):
int x = 10;
int *ip = &x;
std::cout << *ip << "\n";
*ip = 12;
std::cout << x << "\n";
Nous avons un int * pointant vers la mémoire occupée par un int et ceci est un aliasing valide. L'optimiseur doit supposer que les affectations via ip pourraient mettre à jour la valeur occupée par x .
L'exemple suivant montre un alias qui conduit à un comportement indéfini ( exemple en direct ):
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?
}
Dans la fonction foo, nous prenons un int * et un float * , dans cet exemple, nous appelons foo et définissons les deux paramètres pour pointer vers le même emplacement mémoire qui dans cet exemple contient un int . Remarque, le reinterpret_cast indique au compilateur de traiter l'expression comme si elle avait le type spécifié par son paramètre de modèle. Dans ce cas, nous lui disons de traiter l'expression & x comme si elle avait le type float * . Nous pouvons naïvement nous attendre à ce que le résultat du deuxième cout soit 0, mais avec l'optimisation activée en utilisant -O2, gcc et clang produisent le résultat suivant:
0
1
Ce qui n'est peut-être pas prévu, mais est parfaitement valide car nous avons invoqué un comportement indéfini. Un flottant ne peut pas alias valablement un objet int . Par conséquent, l'optimiseur peut supposer que la constante 1 stockée lorsque le déréférencement i sera la valeur de retour puisqu'un magasin via f n'a pas pu affecter valablement un objet int . Brancher le code dans l'Explorateur de compilateur montre que c'est exactement ce qui se passe ( exemple en direct ):
foo(float*, int*): # @foo(float*, int*)
mov dword ptr [rsi], 1
mov dword ptr [rdi], 0
mov eax, 1
ret
L'optimiseur utilisant l' analyse d'alias basée sur le type (TBAA) suppose que 1 sera renvoyé et déplace directement la valeur constante dans le registre eax qui contient la valeur de retour. TBAA utilise les règles de langues sur les types autorisés à alias pour optimiser les chargements et les magasins. Dans ce cas, TBAA sait qu'un float ne peut pas alias et int et optimise la charge de i .
Maintenant, au livre de règles
Que dit exactement la norme que nous sommes autorisés et non autorisés à le faire? Le langage standard n'est pas simple, donc pour chaque élément, je vais essayer de fournir des exemples de code qui en démontrent le sens.
Que dit la norme C11?
La norme C11 dit ce qui suit dans la section 6.5 Expressions, paragraphe 7 :
Un objet doit avoir sa valeur stockée accessible uniquement par une expression lvalue qui a l'un des types suivants: 88)
- un type compatible avec le type effectif de l'objet,
int x = 1;
int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type int which is compatible with int
- une version qualifiée d'un type compatible avec le type effectif de l'objet,
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
- un type qui est le type signé ou non signé correspondant au type effectif de l'objet,
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 a une extension et qui permet également d' assigner int * non signé à int * même s'il ne s'agit pas de types compatibles.
- un type qui est le type signé ou non signé correspondant à une version qualifiée du type effectif de l'objet,
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
- un type d'agrégat ou d'union qui inclut l'un des types susmentionnés parmi ses membres (y compris, récursivement, un membre d'une union sous-agrégée ou contenue), ou
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 );
- un type de caractère.
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.
Ce que dit le projet de norme C ++ 17
Le projet de norme C ++ 17 dans la section [basic.lval] paragraphe 11 dit:
Si un programme tente d'accéder à la valeur stockée d'un objet via une valeur gl autre que l'un des types suivants, le comportement n'est pas défini: 63
(11.1) - le type dynamique de l'objet,
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) - une version qualifiée cv du type dynamique de l'objet,
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) - un type similaire (tel que défini en 7.5) au type dynamique de l'objet,
(11.4) - un type qui est le type signé ou non signé correspondant au type dynamique de l'objet,
// 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) - un type qui est le type signé ou non signé correspondant à une version qualifiée cv du type dynamique de l'objet,
signed int foo( const signed int &si1, int &si2); // Hard to show this one assumes aliasing
(11.6) - un type d'agrégat ou d'union qui inclut l'un des types susmentionnés parmi ses éléments ou membres de données non statiques (y compris, récursivement, un élément ou un membre de données non statique d'une union sous-agrégée ou contenue),
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) - un type qui est un type de classe de base (éventuellement qualifié cv) du type dynamique de l'objet,
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) - un type char, unsigned char ou 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
}
Il convient de noter que le caractère signé n'est pas inclus dans la liste ci-dessus, c'est une différence notable par rapport à C qui dit un type de caractère .
Qu'est-ce que le type Punning
Nous sommes arrivés à ce point et nous nous demandons peut-être pourquoi voudrions-nous nous alias? La réponse est généralement de taper calembour , souvent les méthodes utilisées violent les règles strictes d'alias.
Parfois, nous voulons contourner le système de types et interpréter un objet comme un type différent. C'est ce qu'on appelle le type punning , pour réinterpréter un segment de mémoire comme un autre type. Le repérage de type est utile pour les tâches qui souhaitent accéder à la représentation sous-jacente d'un objet à visualiser, transporter ou manipuler. Les domaines typiques que nous trouvons le type punning utilisé sont les compilateurs, la sérialisation, le code réseau, etc.
Traditionnellement, cela a été accompli en prenant l'adresse de l'objet, en le convertissant en un pointeur du type auquel nous voulons le réinterpréter, puis en accédant à la valeur, ou en d'autres termes par un aliasing. Par exemple:
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 ) ;
Comme nous l'avons vu précédemment, ce n'est pas un aliasing valide, nous invoquons donc un comportement non défini. Mais traditionnellement, les compilateurs ne profitaient pas de règles d'alias strictes et ce type de code fonctionnait généralement bien, les développeurs se sont malheureusement habitués à faire les choses de cette façon. Une méthode alternative courante pour la punition de type consiste à utiliser les unions, ce qui est valide en C mais un comportement non défini en C ++ ( voir l'exemple en direct ):
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
Cela n'est pas valide en C ++ et certains considèrent que le but des unions est uniquement d'implémenter des types de variantes et estiment que l'utilisation des unions pour le punning de type est un abus.
Comment pouvons-nous taper Pun correctement?
La méthode standard pour la punition de type en C et C ++ est memcpy . Cela peut sembler un peu lourd, mais l'optimiseur doit reconnaître l'utilisation de memcpy pour le type punning et l'optimiser et générer un registre pour enregistrer le mouvement. Par exemple, si nous savons que int64_t a la même taille que double :
static_assert( sizeof( double ) == sizeof( int64_t ) ); // C++17 does not require a message
nous pouvons utiliser memcpy :
void func1( double d ) {
std::int64_t n;
std::memcpy(&n, &d, sizeof d);
//...
À un niveau d'optimisation suffisant, tout compilateur moderne décent génère un code identique à la méthode reinterpret_cast ou la méthode d' union mentionnée précédemment pour le découpage de type . En examinant le code généré, nous voyons qu'il utilise simplement register mov ( exemple de l'explorateur de compilation en direct ).
C ++ 20 et bit_cast
En C ++ 20, nous pouvons gagner bit_cast ( implémentation disponible dans le lien de la proposition ) qui donne un moyen simple et sûr de taper-pun ainsi que d'être utilisable dans un contexte constexpr.
Ce qui suit est un exemple d'utilisation de bit_cast pour taper pun un entier non signé à flotter ( voir en direct ):
std::cout << bit_cast<float>(0x447a0000) << "\n" ; //assuming sizeof(float) == sizeof(unsigned int)
Dans le cas où les types To et From n'ont pas la même taille, il nous faut utiliser une structure intermédiaire15. Nous utiliserons une structure contenant un tableau de caractères sizeof (int non signé) ( suppose un entier non signé de 4 octets ) comme étant le type From et un entier non signé comme 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 ;
}
Il est regrettable que nous ayons besoin de ce type intermédiaire mais c'est la contrainte actuelle de bit_cast .
Détecter les violations d'alias strictes
Nous n'avons pas beaucoup de bons outils pour intercepter l'aliasing strict en C ++, les outils dont nous disposons vont détecter certains cas de violations d'aliasing strictes et certains cas de chargements et de magasins mal alignés.
gcc utilisant l'indicateur -fstrict-aliasing et -Wstrict-aliasing peut intercepter certains cas, mais pas sans faux positifs / négatifs. Par exemple, les cas suivants généreront un avertissement dans gcc ( voir en direct ):
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)));
bien qu'il n'attrapera pas ce cas supplémentaire ( voir en direct ):
int *p;
p=&a;
printf("%i\n", j = *(reinterpret_cast<short*>(p)));
Bien que clang autorise ces indicateurs, il n'applique apparemment pas les avertissements.
Un autre outil dont nous disposons est ASan qui peut capturer des charges et des magasins mal alignés. Bien qu'il ne s'agisse pas directement de violations d'alias strictes, elles sont le résultat commun de violations d'alias strictes. Par exemple, les cas suivants génèrent des erreurs d'exécution lorsqu'ils sont créés avec clang en utilisant -fsanitize = adresse
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]
Le dernier outil que je recommanderai est spécifique au C ++ et pas strictement un outil mais une pratique de codage, n'autorisez pas les conversions de style C. Gcc et clang produiront un diagnostic pour les modèles de style C à l'aide de -Wold-style-cast . Cela forcera tous les jeux de mots de type non défini à utiliser reinterpret_cast, en général, reinterpret_cast devrait être un indicateur pour une révision plus approfondie du code. Il est également plus facile de rechercher dans votre base de code reinterpret_cast pour effectuer un audit.
Pour C, nous avons tous les outils déjà couverts et nous avons également tis-interpreter, un analyseur statique qui analyse de manière exhaustive un programme pour un grand sous-ensemble du langage C. Étant donné un C verions de l'exemple précédent où l'utilisation de -fstrict-aliasing manque un cas ( voir en direct )
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 est capable d'attraper les trois, l'exemple suivant appelle tis-kernal comme tis-interpreter (la sortie est éditée pour plus de concision):
./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.
Enfin, il y a TySan qui est actuellement en développement. Cet assainisseur ajoute des informations de vérification de type dans un segment de mémoire fantôme et vérifie les accès pour voir s'ils violent les règles d'alias. L'outil devrait potentiellement être en mesure de détecter toutes les violations d'alias, mais il peut avoir un gros temps d'exécution.
cetc++faq.