On Wed, 27 Feb 2008 18:56:42 +0100, David Côme :int a; //(1)
Jusque-là, pas de problème, même si l'utilité d'un tel code
m'échappe.
cout<< a; // (2)
C'est de toutes façons un comportement indéfini : dans le
meilleur des cas, ça affichera un entier, sans qu'il soit
possible d'en prévoir la valeur à l'avance.
Il me semble que selon la norme, c'est un comportement
indéfini tout court (On ne peut pas du tout prévoir le
comportement du code) ; toutefois, en pratique, je
m'attendrais à ce qu'un entier quelconque soit effectivement
affiché. Et il y a même de bonnes chances pour que ce soit le
même à chaque exécution, tant qu'on ne recompile pas.
On Wed, 27 Feb 2008 18:56:42 +0100, David Côme <davidc...@wanadoo.fr>:
int a; //(1)
Jusque-là, pas de problème, même si l'utilité d'un tel code
m'échappe.
cout<< a; // (2)
C'est de toutes façons un comportement indéfini : dans le
meilleur des cas, ça affichera un entier, sans qu'il soit
possible d'en prévoir la valeur à l'avance.
Il me semble que selon la norme, c'est un comportement
indéfini tout court (On ne peut pas du tout prévoir le
comportement du code) ; toutefois, en pratique, je
m'attendrais à ce qu'un entier quelconque soit effectivement
affiché. Et il y a même de bonnes chances pour que ce soit le
même à chaque exécution, tant qu'on ne recompile pas.
On Wed, 27 Feb 2008 18:56:42 +0100, David Côme :int a; //(1)
Jusque-là, pas de problème, même si l'utilité d'un tel code
m'échappe.
cout<< a; // (2)
C'est de toutes façons un comportement indéfini : dans le
meilleur des cas, ça affichera un entier, sans qu'il soit
possible d'en prévoir la valeur à l'avance.
Il me semble que selon la norme, c'est un comportement
indéfini tout court (On ne peut pas du tout prévoir le
comportement du code) ; toutefois, en pratique, je
m'attendrais à ce qu'un entier quelconque soit effectivement
affiché. Et il y a même de bonnes chances pour que ce soit le
même à chaque exécution, tant qu'on ne recompile pas.
Fabien LE LEZ writes:On Wed, 27 Feb 2008 18:56:42 +0100, David Côme
:int a; //(1)
Jusque-là, pas de problème, même si l'utilité d'un tel code
m'échappe.cout<< a; // (2)
C'est de toutes façons un comportement indéfini : dans le
meilleur des cas, ça affichera un entier, sans qu'il soit
possible d'en prévoir la valeur à l'avance.
Il me semble que selon la norme, c'est un comportement
indéfini tout court (On ne peut pas du tout prévoir le
comportement du code) ;
J'ai pas vérifié, mais c'est ce que je pense. En particulier,
ça peut être une valeur déclanchant une exception (trois cas
plausibles: la représentation de ce qui serait -0 sur une
machine en complément à 1 ou grandeur et signe qui n'admet pas
de -0; mauvais tags sur une machine où les valeurs ont un tag;
il y a eu une machine n'ayant que des nombres en virgule
flottante, mais où certaines opérations trappaient si une
donnée n'était pas entière).
Et ca dépend aussi du système, tous ne remettent pas toute la
mémoire à 0 entre processus (c'est certainement une mauvaise
idée de ne pas le faire sur des machines à usage général).
Fabien LE LEZ <grams...@gramster.com> writes:
On Wed, 27 Feb 2008 18:56:42 +0100, David Côme
<davidc...@wanadoo.fr>:
int a; //(1)
Jusque-là, pas de problème, même si l'utilité d'un tel code
m'échappe.
cout<< a; // (2)
C'est de toutes façons un comportement indéfini : dans le
meilleur des cas, ça affichera un entier, sans qu'il soit
possible d'en prévoir la valeur à l'avance.
Il me semble que selon la norme, c'est un comportement
indéfini tout court (On ne peut pas du tout prévoir le
comportement du code) ;
J'ai pas vérifié, mais c'est ce que je pense. En particulier,
ça peut être une valeur déclanchant une exception (trois cas
plausibles: la représentation de ce qui serait -0 sur une
machine en complément à 1 ou grandeur et signe qui n'admet pas
de -0; mauvais tags sur une machine où les valeurs ont un tag;
il y a eu une machine n'ayant que des nombres en virgule
flottante, mais où certaines opérations trappaient si une
donnée n'était pas entière).
Et ca dépend aussi du système, tous ne remettent pas toute la
mémoire à 0 entre processus (c'est certainement une mauvaise
idée de ne pas le faire sur des machines à usage général).
Fabien LE LEZ writes:On Wed, 27 Feb 2008 18:56:42 +0100, David Côme
:int a; //(1)
Jusque-là, pas de problème, même si l'utilité d'un tel code
m'échappe.cout<< a; // (2)
C'est de toutes façons un comportement indéfini : dans le
meilleur des cas, ça affichera un entier, sans qu'il soit
possible d'en prévoir la valeur à l'avance.
Il me semble que selon la norme, c'est un comportement
indéfini tout court (On ne peut pas du tout prévoir le
comportement du code) ;
J'ai pas vérifié, mais c'est ce que je pense. En particulier,
ça peut être une valeur déclanchant une exception (trois cas
plausibles: la représentation de ce qui serait -0 sur une
machine en complément à 1 ou grandeur et signe qui n'admet pas
de -0; mauvais tags sur une machine où les valeurs ont un tag;
il y a eu une machine n'ayant que des nombres en virgule
flottante, mais où certaines opérations trappaient si une
donnée n'était pas entière).
Et ca dépend aussi du système, tous ne remettent pas toute la
mémoire à 0 entre processus (c'est certainement une mauvaise
idée de ne pas le faire sur des machines à usage général).
Gabriel Dos Reis wrote on 27/02/2008 23:37: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
???
So ?
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
Gabriel Dos Reis wrote on 27/02/2008 23:37:
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
???
So ?
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
Gabriel Dos Reis wrote on 27/02/2008 23:37: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
???
So ?
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
Sylvain writes:
On peut aussi
parfaitement imaginer une implémentation qui vérifierait
dynamiquement la non utilisation de variables non intialisées.
Sylvain <noS...@mail.net> writes:
On peut aussi
parfaitement imaginer une implémentation qui vérifierait
dynamiquement la non utilisation de variables non intialisées.
Sylvain writes:
On peut aussi
parfaitement imaginer une implémentation qui vérifierait
dynamiquement la non utilisation de variables non intialisées.
On Feb 28, 6:25 am, Jean-Marc Bourguet wrote:Sylvain writes:
On peut aussi
parfaitement imaginer une implémentation qui vérifierait
dynamiquement la non utilisation de variables non intialisées.
Pas besoin de l'imaginer. Chez la plupart de mes clients, on
interdisait le déployement du code sans qu'il ait tourné sur un
tel système (Purify, en l'occurance). (Je me rappelle le
problème que ça a causé quand on voulait écrire sur disque une
struct avec un char[n] initializé avec strcpy(). Purify râlait
bien qu'on écrivait des octets qui n'avaient pas été
initialisés.)
On Feb 28, 6:25 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Sylvain <noS...@mail.net> writes:
On peut aussi
parfaitement imaginer une implémentation qui vérifierait
dynamiquement la non utilisation de variables non intialisées.
Pas besoin de l'imaginer. Chez la plupart de mes clients, on
interdisait le déployement du code sans qu'il ait tourné sur un
tel système (Purify, en l'occurance). (Je me rappelle le
problème que ça a causé quand on voulait écrire sur disque une
struct avec un char[n] initializé avec strcpy(). Purify râlait
bien qu'on écrivait des octets qui n'avaient pas été
initialisés.)
On Feb 28, 6:25 am, Jean-Marc Bourguet wrote:Sylvain writes:
On peut aussi
parfaitement imaginer une implémentation qui vérifierait
dynamiquement la non utilisation de variables non intialisées.
Pas besoin de l'imaginer. Chez la plupart de mes clients, on
interdisait le déployement du code sans qu'il ait tourné sur un
tel système (Purify, en l'occurance). (Je me rappelle le
problème que ça a causé quand on voulait écrire sur disque une
struct avec un char[n] initializé avec strcpy(). Purify râlait
bien qu'on écrivait des octets qui n'avaient pas été
initialisés.)
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
James Kanze wrote on 28/02/2008 09:42:so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
même dans ce cas je n'arrive pas à imaginer une valeur
spéciale faisant traper l'injecteur.
James Kanze wrote on 28/02/2008 09:42:
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
même dans ce cas je n'arrive pas à imaginer une valeur
spéciale faisant traper l'injecteur.
James Kanze wrote on 28/02/2008 09:42:so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
même dans ce cas je n'arrive pas à imaginer une valeur
spéciale faisant traper l'injecteur.
On Feb 28, 12:07 pm, Sylvain wrote:James Kanze wrote on 28/02/2008 09:42:so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
Certes, mais il n'est pas forcement bien initialisé à la mise
sous tension. Alors, si tu lis une valeur à une adresse qui n'a
jamais été écrite, tu risques bien un plantage.
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 ?
(Tu peux imaginer ce que tu veux, j'ai déjà travaillé sur de
tels systèmes. En C, en tout cas.)
On Feb 28, 12:07 pm, Sylvain <noS...@mail.net> wrote:
James Kanze wrote on 28/02/2008 09:42:
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
Certes, mais il n'est pas forcement bien initialisé à la mise
sous tension. Alors, si tu lis une valeur à une adresse qui n'a
jamais été écrite, tu risques bien un plantage.
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 ?
(Tu peux imaginer ce que tu veux, j'ai déjà travaillé sur de
tels systèmes. En C, en tout cas.)
On Feb 28, 12:07 pm, Sylvain wrote:James Kanze wrote on 28/02/2008 09:42:so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
Certes, mais il n'est pas forcement bien initialisé à la mise
sous tension. Alors, si tu lis une valeur à une adresse qui n'a
jamais été écrite, tu risques bien un plantage.
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 ?
(Tu peux imaginer ce que tu veux, j'ai déjà travaillé sur de
tels systèmes. En C, en tout cas.)
James Kanze wrote on 28/02/2008 15:46:On Feb 28, 12:07 pm, Sylvain wrote:James Kanze wrote on 28/02/2008 09:42:so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
Certes, mais il n'est pas forcement bien initialisé à la mise
sous tension. Alors, si tu lis une valeur à une adresse qui n'a
jamais été écrite, tu risques bien un plantage.
ah bon ?! il y a de la mémoire avec bit de parité (1 bit) ou avec
correction d'erreur (n bits) qui fait exprès de contenir des valeurs
d'erreurs - ou plutôt il existe des cartes dont le controleur mémoire
fait expres de générer n'importe quoi ... je ne savais pas.
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...
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é.
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.
James Kanze wrote on 28/02/2008 15:46:
On Feb 28, 12:07 pm, Sylvain <noS...@mail.net> wrote:
James Kanze wrote on 28/02/2008 09:42:
so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
Certes, mais il n'est pas forcement bien initialisé à la mise
sous tension. Alors, si tu lis une valeur à une adresse qui n'a
jamais été écrite, tu risques bien un plantage.
ah bon ?! il y a de la mémoire avec bit de parité (1 bit) ou avec
correction d'erreur (n bits) qui fait exprès de contenir des valeurs
d'erreurs - ou plutôt il existe des cartes dont le controleur mémoire
fait expres de générer n'importe quoi ... je ne savais pas.
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...
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é.
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.
James Kanze wrote on 28/02/2008 15:46:On Feb 28, 12:07 pm, Sylvain wrote:James Kanze wrote on 28/02/2008 09:42:so, vous avez des machines sur lesquelles un int, disons 32
bits, peut contenir toutes les valuers entières entre 0x0 et
0xFFFFFFFF *plus* d'autres valeurs, accessoirement invalides
???
C'est tout à fait concevable, et il a même existé des systèmes
où la mémoire a des bits de parité. Invisible au programme, mais
initialisés uniquement à la première écriture.
la mémoire avec parité ou encore ECC existe toujours. ses
états sont invisibles du code utilisateur comme de toute
librairie standard, y compris celle de cout.
Certes, mais il n'est pas forcement bien initialisé à la mise
sous tension. Alors, si tu lis une valeur à une adresse qui n'a
jamais été écrite, tu risques bien un plantage.
ah bon ?! il y a de la mémoire avec bit de parité (1 bit) ou avec
correction d'erreur (n bits) qui fait exprès de contenir des valeurs
d'erreurs - ou plutôt il existe des cartes dont le controleur mémoire
fait expres de générer n'importe quoi ... je ne savais pas.
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...
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é.
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.