C11 liées à la correction de la langue

Question

Le code suivant est un exemple de la C11 standard §6.5.2.3:

struct t1 { int m; }; 
struct t2 { int m; }; 
int f(struct t1 *p1, struct t2 *p2) 
{ 
    if (p1->m < 0) 
     p2->m = -p2->m; 
    return p1->m; 
} 
int g() 
{ 
    union { 
     struct t1 s1; 
     struct t2 s2; 
    } u; 
    /* ... */ 
    return f(&u.s1, &u.s2); 
} 

Comme par C11, la dernière ligne à l'intérieur g() est invalide. Pourquoi ça?

Answer 1

L'exemple provient de l'exemple 3 du §6.5.2.3 Membres de structure et d'union de l'ISO/CEI 9899: 2011. L'un des paragraphes précédents est (accent ajouté):

¶6 une garantie spéciale est faite afin de simplifier l'utilisation des syndicats: si un syndicat contient plusieurs structures qui partagent une séquence initiale commune (voir ci-dessous), et si l'objet union contient actuellement l'une de ces structures, il est permis d'inspecter la partie initiale commune de l'une d'entre elles partout où une déclaration du type complété de l'union est visible. Deux structures partagent une séquence initiale commune si les membres correspondants ont des types compatibles (et, pour les bits-champs, les mêmes largeurs) pour une séquence d'un ou plusieurs membres initiaux.

Le code cité dans la question est précédée du commentaire:

Ce qui suit est pas un fragment valide (parce que le type d'union ne sont pas visibles dans la fonction f).

Cela a maintenant du sens à la lumière de l'instruction en surbrillance. Le code g() utilise la séquence initiale commune, mais cela s'applique uniquement lorsque le union est visible et qu'il n'est pas visible dans f().

Le problème est également celui de l'aliasing strict. C'est un sujet complexe. Voir What is the strict aliasing rule? pour les détails.

Pour tout ce que cela vaut, GCC 7.1.0 ne signale pas le problème, même sous des options d'avertissement rigoureuses. Ni ne Clang, même avec l'option -Weverything:

clang -O3 -g -std=c11 -Wall -Wextra -Werror -Wmissing-prototypes \ 
    -Wstrict-prototypes -Weverything -pedantic … 

Answer 2

Ceci est dû à la règle "de type efficace". Si vous voyez f isolé, les deux arguments ont un type différent et le compilateur est autorisé à effectuer certaines optimisations.

Ici, p1 est accédé deux fois. Si p1 et p2 sont supposés être différents, le compilateur n'a pas besoin de recharger la valeur de p1 pour return puisqu'il ne peut pas avoir changé.

f est un code valide, et l'optimisation est valide.

L'appeler avec le même objet, dans g, n'est pas valide, car sans voir que les deux peuvent provenir du même union le compilateur peut ne pas prendre de dispositions pour éviter l'optimisation. Ceci est l'un des cas, où toute la charge de prouver qu'un appel est valide repose sur l'utilisateur d'une fonction, généralement aucun compilateur ne peut vous avertir à ce sujet si f et g se trouvent dans différentes unités de traduction.