Bonjour,
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
J'ai cru que c'était un problème de point de séquencement ou d'ordre
d'évaluation des arguments mais j'ai l'impression que c'est plus grave
que ça.
Est-ce que le "undefined" dont parle gcc est un "undefined behavior" ?
Est-ce que je tomberais sous le coup de
A.6.2 Undefined behavior
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Le point de séquencement se produit à la fin de l'appel et non pas après
l'évaluation de _chaque_ argument, n'est-ce pas ? Car je trouve ceci pas
très clair :
Bonjour,
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
candide@candide-desktop:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
J'ai cru que c'était un problème de point de séquencement ou d'ordre
d'évaluation des arguments mais j'ai l'impression que c'est plus grave
que ça.
Est-ce que le "undefined" dont parle gcc est un "undefined behavior" ?
Est-ce que je tomberais sous le coup de
A.6.2 Undefined behavior
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Le point de séquencement se produit à la fin de l'appel et non pas après
l'évaluation de _chaque_ argument, n'est-ce pas ? Car je trouve ceci pas
très clair :
Bonjour,
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
J'ai cru que c'était un problème de point de séquencement ou d'ordre
d'évaluation des arguments mais j'ai l'impression que c'est plus grave
que ça.
Est-ce que le "undefined" dont parle gcc est un "undefined behavior" ?
Est-ce que je tomberais sous le coup de
A.6.2 Undefined behavior
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Le point de séquencement se produit à la fin de l'appel et non pas après
l'évaluation de _chaque_ argument, n'est-ce pas ? Car je trouve ceci pas
très clair :
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Exactement.
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Exactement.
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Exactement.
ii) object is modified and accessed other than to determine the new value
ii) object is modified and accessed other than to determine the new value
ii) object is modified and accessed other than to determine the new value
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Exactement.
Très exactement, qu'est-ce qui n'est pas respecté ?
Ceci :
i) object is modified more than once,
ou bien ceci :
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Exactement.
Très exactement, qu'est-ce qui n'est pas respecté ?
Ceci :
i) object is modified more than once,
ou bien ceci :
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).
(...)
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Exactement.
Très exactement, qu'est-ce qui n'est pas respecté ?
Ceci :
i) object is modified more than once,
ou bien ceci :
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
candide@candide-desktop:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
J'ai lu vos explications mais ce n'est toujours pas limpide. La phrase
ci-dessus (extrait de C90, la version de C99 étant légèrement
différente) signifie-elle :
"[Le comportement est indéterminé si] Entre deux points de séquencement,
un objet est modifié plus d'une fois ou s'il est modifié et lu(*) dans
un autre but que de déterminer sa nouvelle valeur"
(*)"est accédé" ne me semble pas français. C99 utilise le terme de "lu".
Est-ce que ce "other than ..." est destiné à nous autoriser à écrire :
printf("%d", i++);
(sans conviction : i est bien modifié et lu et i++ donne la nouvelle
valeur).
Mais, la deuxième expression i dans
printf("%d %d", i++, i );
a bien pour but de déterminer la nouvelle valeur, donc le "other than"
me dit que j'ai le droit, non ?
Sinon, je comprends pas fondamentalement pourquoi ceci
printf("%d %p", i++, (void *)&i );
m'envoie le même genre de warning que ci-dessus,
parce que (void *)&i ne cherche pas à déterminer la nouvelle valeur de
l'objet modifié, elle cherche à accéder à son adresse.
-----------------------------------------------------------------
In a[i] = i++ the value of i is both read and modified and the process
of reading the value of i is independent of the process of calculating
the new value to be written to i. So a[i] = i++ violates the requirement
"Furthermore, the prior value shall be accessed only to determine the
value to be stored".
-----------------------------------------------------------------
A défaut d'expliquer les arcanes de la norme, je pense qu'un manuel de C
devrait mettre en garde contre ce genre de comportement tordu.
Sinon, toujours à propos des points de séquencement, dans la fclc-faq
(il y a l'équivalent du problème dans la clc-faq) :
-----------------------------------------------------------------
10.6 En est-il de même pour i++ * i++ ?
Oui. La norme ne précise pas pour les opérateurs binaires dans
quel ordre les opérandes sont évalués.
-----------------------------------------------------------------
Je trouve cette explication vraiment douteuse (désolé, je ne veux
blesser personne).
Si c'était une affaire d'ordre d'évaluation, on
aurait a priori, un résultat dépendant de l'implémentation. Non, je
pense qu'il faut invoquer le point de la norme déjà signalé. S'il n'y
avait pas ce point, vu qu'il n'y de point de séquencement qu'à la fin de
l'expression, si au départ i=5, la valeur retournée devrait être 25
(indépendamment de l'ordre d'évaluation), non ?
Au passage, la réponse à la question précédente n'est vraiment pas
satisfaisante :
"
Ce genre d'expression fait partie des « undefined
behaviour », ou comportement indéfini. Cela signifie que le
résultat d'une telle opération dépend du compilateur.
L'opérateur ++ modifie la valeur de i, alors que
celle-ci est utilisée ailleurs dans l'expression.
C'est ce que l'on appelle un « effet de bords »."
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).
An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
J'ai lu vos explications mais ce n'est toujours pas limpide. La phrase
ci-dessus (extrait de C90, la version de C99 étant légèrement
différente) signifie-elle :
"[Le comportement est indéterminé si] Entre deux points de séquencement,
un objet est modifié plus d'une fois ou s'il est modifié et lu(*) dans
un autre but que de déterminer sa nouvelle valeur"
(*)"est accédé" ne me semble pas français. C99 utilise le terme de "lu".
Est-ce que ce "other than ..." est destiné à nous autoriser à écrire :
printf("%d", i++);
(sans conviction : i est bien modifié et lu et i++ donne la nouvelle
valeur).
Mais, la deuxième expression i dans
printf("%d %d", i++, i );
a bien pour but de déterminer la nouvelle valeur, donc le "other than"
me dit que j'ai le droit, non ?
Sinon, je comprends pas fondamentalement pourquoi ceci
printf("%d %p", i++, (void *)&i );
m'envoie le même genre de warning que ci-dessus,
parce que (void *)&i ne cherche pas à déterminer la nouvelle valeur de
l'objet modifié, elle cherche à accéder à son adresse.
-----------------------------------------------------------------
In a[i] = i++ the value of i is both read and modified and the process
of reading the value of i is independent of the process of calculating
the new value to be written to i. So a[i] = i++ violates the requirement
"Furthermore, the prior value shall be accessed only to determine the
value to be stored".
-----------------------------------------------------------------
A défaut d'expliquer les arcanes de la norme, je pense qu'un manuel de C
devrait mettre en garde contre ce genre de comportement tordu.
Sinon, toujours à propos des points de séquencement, dans la fclc-faq
(il y a l'équivalent du problème dans la clc-faq) :
-----------------------------------------------------------------
10.6 En est-il de même pour i++ * i++ ?
Oui. La norme ne précise pas pour les opérateurs binaires dans
quel ordre les opérandes sont évalués.
-----------------------------------------------------------------
Je trouve cette explication vraiment douteuse (désolé, je ne veux
blesser personne).
Si c'était une affaire d'ordre d'évaluation, on
aurait a priori, un résultat dépendant de l'implémentation. Non, je
pense qu'il faut invoquer le point de la norme déjà signalé. S'il n'y
avait pas ce point, vu qu'il n'y de point de séquencement qu'à la fin de
l'expression, si au départ i=5, la valeur retournée devrait être 25
(indépendamment de l'ordre d'évaluation), non ?
Au passage, la réponse à la question précédente n'est vraiment pas
satisfaisante :
"
Ce genre d'expression fait partie des « undefined
behaviour », ou comportement indéfini. Cela signifie que le
résultat d'une telle opération dépend du compilateur.
L'opérateur ++ modifie la valeur de i, alors que
celle-ci est utilisée ailleurs dans l'expression.
C'est ce que l'on appelle un « effet de bords »."
ii) object is modified and accessed other than to determine the new value
(ce dernier point ne me paraissant pas très clair).An object is modified more than once, or is modified and accessed
other than to determine the new value, between two sequence points
J'ai lu vos explications mais ce n'est toujours pas limpide. La phrase
ci-dessus (extrait de C90, la version de C99 étant légèrement
différente) signifie-elle :
"[Le comportement est indéterminé si] Entre deux points de séquencement,
un objet est modifié plus d'une fois ou s'il est modifié et lu(*) dans
un autre but que de déterminer sa nouvelle valeur"
(*)"est accédé" ne me semble pas français. C99 utilise le terme de "lu".
Est-ce que ce "other than ..." est destiné à nous autoriser à écrire :
printf("%d", i++);
(sans conviction : i est bien modifié et lu et i++ donne la nouvelle
valeur).
Mais, la deuxième expression i dans
printf("%d %d", i++, i );
a bien pour but de déterminer la nouvelle valeur, donc le "other than"
me dit que j'ai le droit, non ?
Sinon, je comprends pas fondamentalement pourquoi ceci
printf("%d %p", i++, (void *)&i );
m'envoie le même genre de warning que ci-dessus,
parce que (void *)&i ne cherche pas à déterminer la nouvelle valeur de
l'objet modifié, elle cherche à accéder à son adresse.
-----------------------------------------------------------------
In a[i] = i++ the value of i is both read and modified and the process
of reading the value of i is independent of the process of calculating
the new value to be written to i. So a[i] = i++ violates the requirement
"Furthermore, the prior value shall be accessed only to determine the
value to be stored".
-----------------------------------------------------------------
A défaut d'expliquer les arcanes de la norme, je pense qu'un manuel de C
devrait mettre en garde contre ce genre de comportement tordu.
Sinon, toujours à propos des points de séquencement, dans la fclc-faq
(il y a l'équivalent du problème dans la clc-faq) :
-----------------------------------------------------------------
10.6 En est-il de même pour i++ * i++ ?
Oui. La norme ne précise pas pour les opérateurs binaires dans
quel ordre les opérandes sont évalués.
-----------------------------------------------------------------
Je trouve cette explication vraiment douteuse (désolé, je ne veux
blesser personne).
Si c'était une affaire d'ordre d'évaluation, on
aurait a priori, un résultat dépendant de l'implémentation. Non, je
pense qu'il faut invoquer le point de la norme déjà signalé. S'il n'y
avait pas ce point, vu qu'il n'y de point de séquencement qu'à la fin de
l'expression, si au départ i=5, la valeur retournée devrait être 25
(indépendamment de l'ordre d'évaluation), non ?
Au passage, la réponse à la question précédente n'est vraiment pas
satisfaisante :
"
Ce genre d'expression fait partie des « undefined
behaviour », ou comportement indéfini. Cela signifie que le
résultat d'une telle opération dépend du compilateur.
L'opérateur ++ modifie la valeur de i, alors que
celle-ci est utilisée ailleurs dans l'expression.
C'est ce que l'on appelle un « effet de bords »."
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
Une variante qui elle passe sans crier :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d n", 0*i++ + i);
return 0;
}
----------------------
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
candide@candide-desktop:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
Une variante qui elle passe sans crier :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d n", 0*i++ + i);
return 0;
}
----------------------
Soit le code :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d %d n", i++,i);
return 0;
}
----------------------
qui, à la compilation, m'affiche ceci :
----------------------
:~$ gcc -W -Wall -pedantic -o x test.c
test.c: In function «main":
test.c:7: attention : operation on «i" may be undefined
----------------------
Une variante qui elle passe sans crier :
----------------------
#include <stdio.h>
int main(void)
{
int i = 10;
printf("%d n", 0*i++ + i);
return 0;
}
----------------------
printf("%d %d n", i++,i);
printf("%d %d n", i++,i);
printf("%d %d n", i++,i);