À la mise sous tension, la mémoire contient effectivement
n'importe quoi. (Aussi, la plupart des contrôleurs dont je me
suis servi dans le temps prévoyaient bien une commande pour
écrire des valeurs erronées. Pour des motifs de test, si rien
d'autre. Mais le problème réel, c'est que jusqu'à la première
écriture, le contenu n'est pas défini, et il y a des chances
qu'il soit invalid.)
j'aurais même penser qu'une telle situation ne pouvait pas
durer plus de quelques nanosecondes (temps de "refresh"
moyen), à moins que la mémoire "qui n'a jamais été écrite" ne
soit pas rafraichie...
Dans le cas où je l'ai rencontré, il s'agissait des mémoires
statiques, sans refraiche. Mais je conçois bien aussi des cas où
des mémoires dynamiques ne font pas jouer la détection d'erreurs
lors des cycles de refraiche.
même dans ce cas je n'arrive pas à imaginer une valeur
spéciale faisant traper l'injecteur.
Qu'est-ce qui se passe s'il y a une erreur de parité, alors ?
en ECC ? le controleur l'a déjà corrigé.
Il ne peut pas en corriger toutes les erreurs possibles. Que des
erreurs d'un seul bit, et certaines de deux bits.
avec bit de parité simple, ça dépends du BIOS, mais cela ne
regarde nullement le code - avec variables non initialisées -
chargé; lorsqu'il est chargé, tous ces octets ont une parité
correcte ou le système (le hard!) était déjà défaillant.
Tu parles comme si on chargeait la mémoire à partir d'un disque.
(Dans un système classique, évidemment, il n'y a pas de chances
que ça se produisent, parce que le système écrit toute la
mémoire avant de te la donner.) Moi, j'ai rencontré le problème
dans des systèmes embarqués, avec le programme en PROM, et pas
de disque.
À la mise sous tension, la mémoire contient effectivement
n'importe quoi. (Aussi, la plupart des contrôleurs dont je me
suis servi dans le temps prévoyaient bien une commande pour
écrire des valeurs erronées. Pour des motifs de test, si rien
d'autre. Mais le problème réel, c'est que jusqu'à la première
écriture, le contenu n'est pas défini, et il y a des chances
qu'il soit invalid.)
j'aurais même penser qu'une telle situation ne pouvait pas
durer plus de quelques nanosecondes (temps de "refresh"
moyen), à moins que la mémoire "qui n'a jamais été écrite" ne
soit pas rafraichie...
Dans le cas où je l'ai rencontré, il s'agissait des mémoires
statiques, sans refraiche. Mais je conçois bien aussi des cas où
des mémoires dynamiques ne font pas jouer la détection d'erreurs
lors des cycles de refraiche.
même dans ce cas je n'arrive pas à imaginer une valeur
spéciale faisant traper l'injecteur.
Qu'est-ce qui se passe s'il y a une erreur de parité, alors ?
en ECC ? le controleur l'a déjà corrigé.
Il ne peut pas en corriger toutes les erreurs possibles. Que des
erreurs d'un seul bit, et certaines de deux bits.
avec bit de parité simple, ça dépends du BIOS, mais cela ne
regarde nullement le code - avec variables non initialisées -
chargé; lorsqu'il est chargé, tous ces octets ont une parité
correcte ou le système (le hard!) était déjà défaillant.
Tu parles comme si on chargeait la mémoire à partir d'un disque.
(Dans un système classique, évidemment, il n'y a pas de chances
que ça se produisent, parce que le système écrit toute la
mémoire avant de te la donner.) Moi, j'ai rencontré le problème
dans des systèmes embarqués, avec le programme en PROM, et pas
de disque.
À la mise sous tension, la mémoire contient effectivement
n'importe quoi. (Aussi, la plupart des contrôleurs dont je me
suis servi dans le temps prévoyaient bien une commande pour
écrire des valeurs erronées. Pour des motifs de test, si rien
d'autre. Mais le problème réel, c'est que jusqu'à la première
écriture, le contenu n'est pas défini, et il y a des chances
qu'il soit invalid.)
j'aurais même penser qu'une telle situation ne pouvait pas
durer plus de quelques nanosecondes (temps de "refresh"
moyen), à moins que la mémoire "qui n'a jamais été écrite" ne
soit pas rafraichie...
Dans le cas où je l'ai rencontré, il s'agissait des mémoires
statiques, sans refraiche. Mais je conçois bien aussi des cas où
des mémoires dynamiques ne font pas jouer la détection d'erreurs
lors des cycles de refraiche.
même dans ce cas je n'arrive pas à imaginer une valeur
spéciale faisant traper l'injecteur.
Qu'est-ce qui se passe s'il y a une erreur de parité, alors ?
en ECC ? le controleur l'a déjà corrigé.
Il ne peut pas en corriger toutes les erreurs possibles. Que des
erreurs d'un seul bit, et certaines de deux bits.
avec bit de parité simple, ça dépends du BIOS, mais cela ne
regarde nullement le code - avec variables non initialisées -
chargé; lorsqu'il est chargé, tous ces octets ont une parité
correcte ou le système (le hard!) était déjà défaillant.
Tu parles comme si on chargeait la mémoire à partir d'un disque.
(Dans un système classique, évidemment, il n'y a pas de chances
que ça se produisent, parce que le système écrit toute la
mémoire avant de te la donner.) Moi, j'ai rencontré le problème
dans des systèmes embarqués, avec le programme en PROM, et pas
de disque.
il n'a pas à corriger "toutes les valeurs possibles" d'une variable non
initialisée car cela ne veux strictement rien donne - elle est. elle n'a
pas beson de correction, n'étant pas erronée.
il n'a pas à corriger "toutes les valeurs possibles" d'une variable non
initialisée car cela ne veux strictement rien donne - elle est. elle n'a
pas beson de correction, n'étant pas erronée.
il n'a pas à corriger "toutes les valeurs possibles" d'une variable non
initialisée car cela ne veux strictement rien donne - elle est. elle n'a
pas beson de correction, n'étant pas erronée.
James Kanze wrote on 28/02/2008 22:12:À la mise sous tension, la mémoire contient effectivement
n'importe quoi. (Aussi, la plupart des contrôleurs dont je me
suis servi dans le temps prévoyaient bien une commande pour
écrire des valeurs erronées. Pour des motifs de test, si rien
d'autre. Mais le problème réel, c'est que jusqu'à la première
écriture, le contenu n'est pas défini, et il y a des chances
qu'il soit invalid.)
certes mais ce n'est pas le cas décrit ici.
évidemment toute la mémoire n'est pas vérifié à chaque tic
d'horloge (lorsqu'elle est rafraichie), elle l'est uniquement
lorsqu'elle est lue, or pour que le code: "int x; cout << x;"
soit lu en mémoire et fourni au CPU, il faut qu'il ait été
écrit dans cette mémoire,
lors de cette écriture la valeur int32 (pas 33, ni 36, ni
autre) non initialisée (en supposant que le compilo n'est pas
utilisé un registre) est écrite en mémoire et son CRC est
correctement calculé.
le chargement de la valeur non prédictible a copié tels-quels
tous les bits et a calculé le ou les bits de contrôle, si une
particule cosmique vient basculer un ou 2 bits, le CRC le(s)
corrigera.
il n'a pas à corriger "toutes les valeurs possibles" d'une
variable non initialisée car cela ne veux strictement rien
donne - elle est. elle n'a pas beson de correction, n'étant
pas erronée.
avec bit de parité simple, ça dépends du BIOS, mais cela ne
regarde nullement le code - avec variables non initialisées -
chargé; lorsqu'il est chargé, tous ces octets ont une parité
correcte ou le système (le hard!) était déjà défaillant.
Tu parles comme si on chargeait la mémoire à partir d'un disque.
(Dans un système classique, évidemment, il n'y a pas de chances
que ça se produisent, parce que le système écrit toute la
mémoire avant de te la donner.) Moi, j'ai rencontré le problème
dans des systèmes embarqués, avec le programme en PROM, et pas
de disque.
oui je me plaçais en effet dans ce cas qui me semblait pas trop
anecdotique, un contrôleur [E[E]]PROM utilise toujours un contrôle de
parité (en premier lieu pour se défendre comme les attaques) mais ici
encore il ne détecte que les modifications ayant pu intervenir de
manière ciblée (attaque lumière) ou globale (micro-ondes) sur la PRO M.
il ne se demande pas si un int8 particulier contient tel valeur parce
que c'est le bruit du compilo ou parce que le source contenait une
valeur intentionelle.
en résumé, estimer qu'il peut exister des compilos suffisamment malin
pour insérer un trap (une assertion) lorsqu'une variable non initialis ée
est utilisée - tout en étant assez bête pour ne pas en faire une err eur
de compilo - est recevable. (un compilo C51 - embarqué - n'insère pas de
tel code).
dire qu'une variable n bits non initialisée peut faire traper le systè me
parce qu'elle contient une valeur n+m bits qu'elle ne peut pas
contenir est une erreur.
James Kanze wrote on 28/02/2008 22:12:
À la mise sous tension, la mémoire contient effectivement
n'importe quoi. (Aussi, la plupart des contrôleurs dont je me
suis servi dans le temps prévoyaient bien une commande pour
écrire des valeurs erronées. Pour des motifs de test, si rien
d'autre. Mais le problème réel, c'est que jusqu'à la première
écriture, le contenu n'est pas défini, et il y a des chances
qu'il soit invalid.)
certes mais ce n'est pas le cas décrit ici.
évidemment toute la mémoire n'est pas vérifié à chaque tic
d'horloge (lorsqu'elle est rafraichie), elle l'est uniquement
lorsqu'elle est lue, or pour que le code: "int x; cout << x;"
soit lu en mémoire et fourni au CPU, il faut qu'il ait été
écrit dans cette mémoire,
lors de cette écriture la valeur int32 (pas 33, ni 36, ni
autre) non initialisée (en supposant que le compilo n'est pas
utilisé un registre) est écrite en mémoire et son CRC est
correctement calculé.
le chargement de la valeur non prédictible a copié tels-quels
tous les bits et a calculé le ou les bits de contrôle, si une
particule cosmique vient basculer un ou 2 bits, le CRC le(s)
corrigera.
il n'a pas à corriger "toutes les valeurs possibles" d'une
variable non initialisée car cela ne veux strictement rien
donne - elle est. elle n'a pas beson de correction, n'étant
pas erronée.
avec bit de parité simple, ça dépends du BIOS, mais cela ne
regarde nullement le code - avec variables non initialisées -
chargé; lorsqu'il est chargé, tous ces octets ont une parité
correcte ou le système (le hard!) était déjà défaillant.
Tu parles comme si on chargeait la mémoire à partir d'un disque.
(Dans un système classique, évidemment, il n'y a pas de chances
que ça se produisent, parce que le système écrit toute la
mémoire avant de te la donner.) Moi, j'ai rencontré le problème
dans des systèmes embarqués, avec le programme en PROM, et pas
de disque.
oui je me plaçais en effet dans ce cas qui me semblait pas trop
anecdotique, un contrôleur [E[E]]PROM utilise toujours un contrôle de
parité (en premier lieu pour se défendre comme les attaques) mais ici
encore il ne détecte que les modifications ayant pu intervenir de
manière ciblée (attaque lumière) ou globale (micro-ondes) sur la PRO M.
il ne se demande pas si un int8 particulier contient tel valeur parce
que c'est le bruit du compilo ou parce que le source contenait une
valeur intentionelle.
en résumé, estimer qu'il peut exister des compilos suffisamment malin
pour insérer un trap (une assertion) lorsqu'une variable non initialis ée
est utilisée - tout en étant assez bête pour ne pas en faire une err eur
de compilo - est recevable. (un compilo C51 - embarqué - n'insère pas de
tel code).
dire qu'une variable n bits non initialisée peut faire traper le systè me
parce qu'elle contient une valeur n+m bits qu'elle ne peut pas
contenir est une erreur.
James Kanze wrote on 28/02/2008 22:12:À la mise sous tension, la mémoire contient effectivement
n'importe quoi. (Aussi, la plupart des contrôleurs dont je me
suis servi dans le temps prévoyaient bien une commande pour
écrire des valeurs erronées. Pour des motifs de test, si rien
d'autre. Mais le problème réel, c'est que jusqu'à la première
écriture, le contenu n'est pas défini, et il y a des chances
qu'il soit invalid.)
certes mais ce n'est pas le cas décrit ici.
évidemment toute la mémoire n'est pas vérifié à chaque tic
d'horloge (lorsqu'elle est rafraichie), elle l'est uniquement
lorsqu'elle est lue, or pour que le code: "int x; cout << x;"
soit lu en mémoire et fourni au CPU, il faut qu'il ait été
écrit dans cette mémoire,
lors de cette écriture la valeur int32 (pas 33, ni 36, ni
autre) non initialisée (en supposant que le compilo n'est pas
utilisé un registre) est écrite en mémoire et son CRC est
correctement calculé.
le chargement de la valeur non prédictible a copié tels-quels
tous les bits et a calculé le ou les bits de contrôle, si une
particule cosmique vient basculer un ou 2 bits, le CRC le(s)
corrigera.
il n'a pas à corriger "toutes les valeurs possibles" d'une
variable non initialisée car cela ne veux strictement rien
donne - elle est. elle n'a pas beson de correction, n'étant
pas erronée.
avec bit de parité simple, ça dépends du BIOS, mais cela ne
regarde nullement le code - avec variables non initialisées -
chargé; lorsqu'il est chargé, tous ces octets ont une parité
correcte ou le système (le hard!) était déjà défaillant.
Tu parles comme si on chargeait la mémoire à partir d'un disque.
(Dans un système classique, évidemment, il n'y a pas de chances
que ça se produisent, parce que le système écrit toute la
mémoire avant de te la donner.) Moi, j'ai rencontré le problème
dans des systèmes embarqués, avec le programme en PROM, et pas
de disque.
oui je me plaçais en effet dans ce cas qui me semblait pas trop
anecdotique, un contrôleur [E[E]]PROM utilise toujours un contrôle de
parité (en premier lieu pour se défendre comme les attaques) mais ici
encore il ne détecte que les modifications ayant pu intervenir de
manière ciblée (attaque lumière) ou globale (micro-ondes) sur la PRO M.
il ne se demande pas si un int8 particulier contient tel valeur parce
que c'est le bruit du compilo ou parce que le source contenait une
valeur intentionelle.
en résumé, estimer qu'il peut exister des compilos suffisamment malin
pour insérer un trap (une assertion) lorsqu'une variable non initialis ée
est utilisée - tout en étant assez bête pour ne pas en faire une err eur
de compilo - est recevable. (un compilo C51 - embarqué - n'insère pas de
tel code).
dire qu'une variable n bits non initialisée peut faire traper le systè me
parce qu'elle contient une valeur n+m bits qu'elle ne peut pas
contenir est une erreur.
Anthony Fleury wrote on 27/02/2008 19:29:Est ce que ce code à un comportement indéfini ?
//iostream est inclue , ...
int a; //(1)
cout<< a; // (2)
Entre autre, a peut très bien contenir une valeur "invalide" pour le
système ("trap value") qui ferait remarquer au-dit système que la
variable utilisée ne l'est pas d'une manière conforme.
j'ai du mal à saisir la finesse de l'indéfinition.
je ne vois ici qu'une imprévision (non connaissance d'une valeur
aléatoire, ou comment se paraphraser).
surtout je ne vois pas ce que serait un *int* "invalide" !!
vous avez des machines sur lesquelles un int, disons 32 bits, peut
contenir toutes les valuers entières entre 0x00000000 et 0xFFFFFFFF
*plus* d'autres valeurs invalides ???
Anthony Fleury wrote on 27/02/2008 19:29:
Est ce que ce code à un comportement indéfini ?
//iostream est inclue , ...
int a; //(1)
cout<< a; // (2)
Entre autre, a peut très bien contenir une valeur "invalide" pour le
système ("trap value") qui ferait remarquer au-dit système que la
variable utilisée ne l'est pas d'une manière conforme.
j'ai du mal à saisir la finesse de l'indéfinition.
je ne vois ici qu'une imprévision (non connaissance d'une valeur
aléatoire, ou comment se paraphraser).
surtout je ne vois pas ce que serait un *int* "invalide" !!
vous avez des machines sur lesquelles un int, disons 32 bits, peut
contenir toutes les valuers entières entre 0x00000000 et 0xFFFFFFFF
*plus* d'autres valeurs invalides ???
Anthony Fleury wrote on 27/02/2008 19:29:Est ce que ce code à un comportement indéfini ?
//iostream est inclue , ...
int a; //(1)
cout<< a; // (2)
Entre autre, a peut très bien contenir une valeur "invalide" pour le
système ("trap value") qui ferait remarquer au-dit système que la
variable utilisée ne l'est pas d'une manière conforme.
j'ai du mal à saisir la finesse de l'indéfinition.
je ne vois ici qu'une imprévision (non connaissance d'une valeur
aléatoire, ou comment se paraphraser).
surtout je ne vois pas ce que serait un *int* "invalide" !!
vous avez des machines sur lesquelles un int, disons 32 bits, peut
contenir toutes les valuers entières entre 0x00000000 et 0xFFFFFFFF
*plus* d'autres valeurs invalides ???
Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Quid du code ci-dessous ?
On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Quid du code ci-dessous ?
On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Quid du code ci-dessous ?
On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
1ère possibilité :
1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
vaut 3
2. Post() est exécutée en entier -> i vaut 4 ; le deuxième temporaire
vaut 3
On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
1ère possibilité :
1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
vaut 3
2. Post() est exécutée en entier -> i vaut 4 ; le deuxième temporaire
vaut 3
On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
1ère possibilité :
1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
vaut 3
2. Post() est exécutée en entier -> i vaut 4 ; le deuxième temporaire
vaut 3
même dans ce cas je n'arrive pas à imaginer une valeur spéciale faisant
traper l'injecteur.
même dans ce cas je n'arrive pas à imaginer une valeur spéciale faisant
traper l'injecteur.
même dans ce cas je n'arrive pas à imaginer une valeur spéciale faisant
traper l'injecteur.
On 2008-02-27, Sylvain wrote:Anthony Fleury wrote on 27/02/2008 19:29:Est ce que ce code à un comportement indéfini ?
//iostream est inclue , ...
int a; //(1)
cout<< a; // (2)
Entre autre, a peut très bien contenir une valeur "invalide" pour le
système ("trap value") qui ferait remarquer au-dit système que la
variable utilisée ne l'est pas d'une manière conforme.
j'ai du mal à saisir la finesse de l'indéfinition. je ne
vois ici qu'une imprévision (non connaissance d'une valeur
aléatoire, ou comment se paraphraser).
surtout je ne vois pas ce que serait un *int* "invalide" !!
vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre
0x00000000 et 0xFFFFFFFF *plus* d'autres valeurs invalides
???
Il y a là un problème de vocabulaire qui peut durer longtemps...
La norme parle de "comportement indéfini" pour tout ce à quoi
elle ne veut pas associer de sémantique.
Après, sur l'ensemble des compilateurs existants à ce jour et
l'ensemble de OS et l'ensemble des processeurs et des mémoires,
ce sera surement un comportement "défini", avec une définition
plus ou moins précise quand même...
Après, l'exemple d'une exécution sous purify est intéressante.
En quoi le triplet gcc/linux/purify ne serait pas une "plateforme
d'exécution" et VC++/Vista le serait il ? Parce qu'aucun code
en production ne l'utilise ? En est-on sûr ?
Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Sauf qu'en plus, la norme C (et donc par extension celle de C++)
évoque bien la notion de "trap representation", qu'on peut évoquer
là à cause de la non-initialisation.
On 2008-02-27, Sylvain <noS...@mail.net> wrote:
Anthony Fleury wrote on 27/02/2008 19:29:
Est ce que ce code à un comportement indéfini ?
//iostream est inclue , ...
int a; //(1)
cout<< a; // (2)
Entre autre, a peut très bien contenir une valeur "invalide" pour le
système ("trap value") qui ferait remarquer au-dit système que la
variable utilisée ne l'est pas d'une manière conforme.
j'ai du mal à saisir la finesse de l'indéfinition. je ne
vois ici qu'une imprévision (non connaissance d'une valeur
aléatoire, ou comment se paraphraser).
surtout je ne vois pas ce que serait un *int* "invalide" !!
vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre
0x00000000 et 0xFFFFFFFF *plus* d'autres valeurs invalides
???
Il y a là un problème de vocabulaire qui peut durer longtemps...
La norme parle de "comportement indéfini" pour tout ce à quoi
elle ne veut pas associer de sémantique.
Après, sur l'ensemble des compilateurs existants à ce jour et
l'ensemble de OS et l'ensemble des processeurs et des mémoires,
ce sera surement un comportement "défini", avec une définition
plus ou moins précise quand même...
Après, l'exemple d'une exécution sous purify est intéressante.
En quoi le triplet gcc/linux/purify ne serait pas une "plateforme
d'exécution" et VC++/Vista le serait il ? Parce qu'aucun code
en production ne l'utilise ? En est-on sûr ?
Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Sauf qu'en plus, la norme C (et donc par extension celle de C++)
évoque bien la notion de "trap representation", qu'on peut évoquer
là à cause de la non-initialisation.
On 2008-02-27, Sylvain wrote:Anthony Fleury wrote on 27/02/2008 19:29:Est ce que ce code à un comportement indéfini ?
//iostream est inclue , ...
int a; //(1)
cout<< a; // (2)
Entre autre, a peut très bien contenir une valeur "invalide" pour le
système ("trap value") qui ferait remarquer au-dit système que la
variable utilisée ne l'est pas d'une manière conforme.
j'ai du mal à saisir la finesse de l'indéfinition. je ne
vois ici qu'une imprévision (non connaissance d'une valeur
aléatoire, ou comment se paraphraser).
surtout je ne vois pas ce que serait un *int* "invalide" !!
vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre
0x00000000 et 0xFFFFFFFF *plus* d'autres valeurs invalides
???
Il y a là un problème de vocabulaire qui peut durer longtemps...
La norme parle de "comportement indéfini" pour tout ce à quoi
elle ne veut pas associer de sémantique.
Après, sur l'ensemble des compilateurs existants à ce jour et
l'ensemble de OS et l'ensemble des processeurs et des mémoires,
ce sera surement un comportement "défini", avec une définition
plus ou moins précise quand même...
Après, l'exemple d'une exécution sous purify est intéressante.
En quoi le triplet gcc/linux/purify ne serait pas une "plateforme
d'exécution" et VC++/Vista le serait il ? Parce qu'aucun code
en production ne l'utilise ? En est-on sûr ?
Ca me rappelle les discutions sur
int i= 2;
int j = ++i * i++;
Les valeurs de i et j sont formellement indéfinies. Dans la
pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
et j entre 4, 6, 9 et 16.
Sauf qu'en plus, la norme C (et donc par extension celle de C++)
évoque bien la notion de "trap representation", qu'on peut évoquer
là à cause de la non-initialisation.
On 2008-02-29, Fabien LE LEZ wrote:On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
1ère possibilité :
1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
vaut 3
2. Post() est exécutée en entier -> i vaut 4 ; le deuxième tempora ire
vaut 3
Tu fais l'hypothèse que l'appel à la fonction est fait "en entier".
On sens bien que ce doit être vrai, mais difficile à trouver
explicitement. Le mieux que je trouve est 6.5.2.2/10 de la norme C
qui dit
"The order of evaluation of the function designator, the actual
arguments and subexpressions within the actual arguments is
unspecified", ce qui milite pour le fait qu'il y ait un ordre
et pas du parallélisme... Et comme l'appel de la fonction
et les ; qui sont dedans sont des points de séquence, en effet,
ton raisonnement doit être le bon.
On 2008-02-29, Fabien LE LEZ <grams...@gramster.com> wrote:
On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
1ère possibilité :
1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
vaut 3
2. Post() est exécutée en entier -> i vaut 4 ; le deuxième tempora ire
vaut 3
Tu fais l'hypothèse que l'appel à la fonction est fait "en entier".
On sens bien que ce doit être vrai, mais difficile à trouver
explicitement. Le mieux que je trouve est 6.5.2.2/10 de la norme C
qui dit
"The order of evaluation of the function designator, the actual
arguments and subexpressions within the actual arguments is
unspecified", ce qui milite pour le fait qu'il y ait un ordre
et pas du parallélisme... Et comme l'appel de la fonction
et les ; qui sont dedans sont des points de séquence, en effet,
ton raisonnement doit être le bon.
On 2008-02-29, Fabien LE LEZ wrote:On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
1ère possibilité :
1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
vaut 3
2. Post() est exécutée en entier -> i vaut 4 ; le deuxième tempora ire
vaut 3
Tu fais l'hypothèse que l'appel à la fonction est fait "en entier".
On sens bien que ce doit être vrai, mais difficile à trouver
explicitement. Le mieux que je trouve est 6.5.2.2/10 de la norme C
qui dit
"The order of evaluation of the function designator, the actual
arguments and subexpressions within the actual arguments is
unspecified", ce qui milite pour le fait qu'il y ait un ordre
et pas du parallélisme... Et comme l'appel de la fonction
et les ; qui sont dedans sont des points de séquence, en effet,
ton raisonnement doit être le bon.