Discussion :

[dinobogan]

Bonjour à tous,

je ne parviens pas à trouver si c'est un undefined behavior ou non.
Voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <stdio.h>
 
int main( void )
{
        int tab[2] = {10, 20};
        int i = 1;
        tab[i] = tab[--i];
        printf( "%d, %d\n", tab[0], tab[1] );
        return 0;
}

En compilant avec gcc v4.2.0 : gcc -std=c99, voici la sortie : "10, 10"
En compilant avec xlC v11.01 ou 13.01, voici la sortie : "10, 20"
Le système est IBM Unix AIX.

xlC semble d'abord effectuer la pré-incrémentation puis l'affectation.

Avez-vous des explications sur cette différence ?

[Bousk]

Je ne connais pas ce compilo xlC mais je dirais que gcc a raison.
tab[i] déplace ça sur tab[1], auquel on affecte tab[--i] qui devrait faire la décrémentation de i, et donc assigner tab[0] à tab[1]
Sur un code aussi court tu devrais comparer le code asm généré, on dirait que xlC assigne tab[1] à tab[1] avant de décrémenter i, en fait une post-décrémentation de i et non une pré-décrémentation, ce qui serait donc un bug de leur part IMO.

[Matt_Houston]

Et moi je vote UB.

D'après la norme (draft N1570), en 6.5§2 :

If a side effect on a scalar object is unsequenced relative to either a different side effect
on the same scalar object or a value computation using the value of the same scalar
object, the behavior is undefined. If there are multiple allowable orderings of the
subexpressions of an expression, the behavior is undefined if such an unsequenced side
effect occurs in any of the orderings.

Or il n'y a pas de sequence point au sein d'une affectation, si l'on en croit 6.8§4 (on apprendra en 6.8.3§2 qu'une affectation est un expression statement) :

[...] Each of the following is a full expression: an initializer that is not part of a compound
literal; the expression in an expression statement; [...] There is a sequence point between the evaluation of a full expression and the
evaluation of the next full expression to be evaluated.

Alors certes on peut toujours interpréter à loisir mais au mieux l'ordre d'évaluation de l'effet de bord et de l'affectation est indéterminé, c'est une raison suffisante pour bannir ce genre de chose.

[dinobogan]

Ok pour l'undefined behavior et la référence à la norme.
Je ne ferais plus jamais comme ça ;-)
Merci !

[Sve@r]

En compilant avec gcc v4.2.0 : gcc -std=c99, voici la sortie : "10, 10"

Bonjour

De mon côté, j'ai compilé avec gcc v4.9.2 (debian8, gcc -std=c99) et j'ai eu "10, 20". Sans dec, j'aurais moi aussi parié sur "10, 10" !!!
Surtout que si je change un seul détail...

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <stdio.h>
 
int main( void )
{
        int tab[2] = {10, 20};
        int i = 1;
        tab[1] = tab[--i];
        printf( "%d, %d\n", tab[0], tab[1] );
        return 0;
}

... j'obtiens bien "10, 10".
C'est bien le fait d'intéger "i" dans la même expression que "--i" qui met la zone !!!

Essayons maintenant de jouer avec ce "i"...

Ici...

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <stdio.h>
 
int main( void )
{
	int tab[2] = {10, 20};
	int i = 1;
	tab[i=i] = tab[--i];
	printf( "%d, %d\n", tab[0], tab[1] );
	return 0;
}

... j'obtiens de nouveau "10 20"

Mais ici...

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
 
int main( void )
{
	int tab[2] = {10, 20};
	int i = 1;
	int j;
	tab[j=i] = tab[--i];
	printf( "%d, %d\n", tab[0], tab[1] );
	return 0;
}

... j'obtiens "10 10" !!!

Intéressant non ?

[sambia39]

Bonjour,

Je ne suis pas tout à fait d’accord à la réponse donnée plus haut sans pour autant dire réellement d’où vient le problème et conclure directement sur ce que dit la norme.

Le problème est effectivement dû à une violation des règles de séquençage et d’accès ; et non a un manque de points de séquence au sein d’une affectation et cela vient plus précisément du fait que la même variable (votre variable i), est modifiée plus d'une fois au sein d’une même expression. Ainsi donc, la valeur finale de votre variable i est indéterminé au moment où l’on exécute cette instruction. La norme à ce sujet peut tout à fait spécifier l'un des deux comportements possibles tab[i]/tab[--i] , mais comme le résultat de la variable ne peut être défini/déterminer en cours d’exécution au sein de cette expression tab[i] = tab[--i] alors tout type d’instruction de la sorte (Voir également du style i= i++); est considéré comme étant un comportement indéterminé et c’est le cas dans votre exemple : la variable i est bien ambigu.

N’oublions pas que la façon dont votre compilateur évalue la chose est totalement laissée à la discrétion des concepteurs de votre compilateur pour différentes raisons; par exemple : le langage de programmation C garantie que les opérateurs && || ? : dont l’opérateur, le plus à gauche, sera évalué en premier ; quant aux autres, cela n’est pas spécifié et donc chaque compilateur fait à sa sauce. D’ailleurs, le résultat fourni par plusieurs de vos compilateurs reflète bien la manière de comment, chaque compilateur implémente la choses.

On peut remarquer que votre expression sur un compilateur xlC fonctionne parce que les concepteurs ont probablement défini des priorités sur l'opérateur/inséré des points de séquences volontairement sur ce genre d’expression de telles manières, à obtenir un comportement bien défini et déterminé. En clair, le compilateur xlC peut tout à fait admettre comme vous l'avez mentionné; procéder d’abord à une pré-incrémentation puis en une affectation. (peut-être à cause des règles de priorité et associativité/tout simplement parce que le compilateur a placé un point de séquence entre les deux instructions.) quand a GCC cela n'est pas le cas, il implémente les choses de manière différente de telle sorte a respecté la norme. GCC va donc émettre un avertissement s’il rencontre ce genre d’instruction pour vous dire, que vous n’avez pas séquencé les instructions et qu'on même temps vous accéder ou modifier la valeur de la variable ‘i’ et donc le résultat de ’i’ ne peut être garantie/ déterminer.

Ceci dit, on peut également se poser la question si le compilateur xlc respecte la norme ou comment il arrive à déterminer la valeur de i sur une telle expression. la ou je rejoins @Bousk c'est sur la lecture/comparaison du code au niveau langage assembleur de votre architecture.

À bientôt,