ayant a l'origine appris le C, j'apprend a présent le C++, et j'ai été
un peu "choqué" de voir que je pouvais faire une déclaration de tableau
ainsi :
int x;
cin>>x;
int tab[x];
je pensais, qu'il n'y avait que 4 méthodes pour déclarer un tableau :
#define MAX 20
int tab[MAX];
ou bien
int tab[20]
ou bien
const int x = 20;
int tab[x];
et enfin
int tab[]={2,3,4};
depuis quand la déclaration d'un tableau avec une variable non
constante est-elle autorisée en C++ ? n'est-ce pas un peu dangereux si
par exemple ma variable est mal "controlée" (ex : x=29299939391992991)
En principe, ta variable ne devrait pas être "mal contrôlée". Ou bien je ne
comprends pas ce que tu entends par cette expression...
et bien par exemple, si on admet que le programmeur a pris TOUTES les sécurités possibles et imaginables pour controler les valeurs prises par x, il y a certains cas, par exemple dans des applications réseau, où x pourrait prendres des valeurs farfelues et imprévisibles venues de l'extérieur du programme... dans ces conditions, déclarer un tableau de dimension x, inconnue donc, me parait assez dangereux.
Je ne comprends pas tes propos : dans tous les langages que je connais, il est possible d'allouer un vecteur (ou tableau, ou buffer, peu importe le nom) d'une taille x, variable. Que proposes tu pour sécuriser ca ? Si tu trouves que c'est mal d'allouer un buffer de 3546159894 octets (à priori, je ne vois pas pourquoi), tu peux mettre un test apres avoir recu x du réseau (genre if(x > (1<<30)) throw "L'application ne gere pas les messages de plus d' 1Go"; )
-- Vincent
En principe, ta variable ne devrait pas être "mal contrôlée". Ou bien je
ne
comprends pas ce que tu entends par cette expression...
et bien par exemple, si on admet que le programmeur a pris TOUTES les
sécurités possibles et imaginables pour controler les valeurs prises
par x, il y a certains cas, par exemple dans des applications réseau,
où x pourrait prendres des valeurs farfelues et imprévisibles venues de
l'extérieur du programme... dans ces conditions, déclarer un tableau de
dimension x, inconnue donc, me parait assez dangereux.
Je ne comprends pas tes propos : dans tous les langages que je connais, il
est possible d'allouer un vecteur (ou tableau, ou buffer, peu importe le
nom) d'une taille x, variable. Que proposes tu pour sécuriser ca ? Si tu
trouves que c'est mal d'allouer un buffer de 3546159894 octets (à priori, je
ne vois pas pourquoi), tu peux mettre un test apres avoir recu x du réseau
(genre if(x > (1<<30)) throw "L'application ne gere pas les messages de plus
d' 1Go"; )
En principe, ta variable ne devrait pas être "mal contrôlée". Ou bien je ne
comprends pas ce que tu entends par cette expression...
et bien par exemple, si on admet que le programmeur a pris TOUTES les sécurités possibles et imaginables pour controler les valeurs prises par x, il y a certains cas, par exemple dans des applications réseau, où x pourrait prendres des valeurs farfelues et imprévisibles venues de l'extérieur du programme... dans ces conditions, déclarer un tableau de dimension x, inconnue donc, me parait assez dangereux.
Je ne comprends pas tes propos : dans tous les langages que je connais, il est possible d'allouer un vecteur (ou tableau, ou buffer, peu importe le nom) d'une taille x, variable. Que proposes tu pour sécuriser ca ? Si tu trouves que c'est mal d'allouer un buffer de 3546159894 octets (à priori, je ne vois pas pourquoi), tu peux mettre un test apres avoir recu x du réseau (genre if(x > (1<<30)) throw "L'application ne gere pas les messages de plus d' 1Go"; )
-- Vincent
Loïc Joly
Nicolas Aunai wrote:
"Fabien LE LEZ" avait écrit le 17/11/2003 :
int x; cin>>x; int tab[x];
Ce n'est pas autorisé en C++ ; par contre il me semble que c'est autorisé en C (sauf le 'cin' bien sûr).
en C99 oui, j'ai été très surpris de l'apprendre.
On peut par contre écrire :
int x; cin>>x; std::vector<int> tab (x);
oui ok, mais là vector s'occupe de la mémoire par derrière...
Bin, là le compilateur s'occupe de la mémoire par derrière. J'ai tu mal à voir ce qui te gêne dans cet exemple.
-- Loïc
Nicolas Aunai wrote:
"Fabien LE LEZ" avait écrit le 17/11/2003 :
int x;
cin>>x;
int tab[x];
Ce n'est pas autorisé en C++ ; par contre il me semble que c'est
autorisé en C (sauf le 'cin' bien sûr).
en C99 oui, j'ai été très surpris de l'apprendre.
On peut par contre écrire :
int x;
cin>>x;
std::vector<int> tab (x);
oui ok, mais là vector s'occupe de la mémoire par derrière...
Bin, là le compilateur s'occupe de la mémoire par derrière. J'ai tu mal
à voir ce qui te gêne dans cet exemple.
On Tue, 18 Nov 2003 13:23:34 +0100, DINH Viêt Hoà wrote:
const int x = 20; int tab[x];
d'ailleurs ceci est-il autorisé en C90 ?
Il me semble que non.
-- ;-)
kanze
Loïc Joly wrote in message news:<bpdrjd$qit$...
Nicolas Aunai wrote:
"Fabien LE LEZ" avait écrit le 17/11/2003 :
int x; cin>>x; int tab[x];
Ce n'est pas autorisé en C++ ; par contre il me semble que c'est autorisé en C (sauf le 'cin' bien sûr).
en C99 oui, j'ai été très surpris de l'apprendre.
On peut par contre écrire :
int x; cin>>x; std::vector<int> tab (x);
oui ok, mais là vector s'occupe de la mémoire par derrière...
Bin, là le compilateur s'occupe de la mémoire par derrière. J'ai tu mal à voir ce qui te gêne dans cet exemple.
Il y a quand même une différence importante entre :
int table[ n ] ; et std::vector< int > table( n ) ;
Dans le premier cas, s'il n'y a pas assez de mémoire, tu as épuisé les ressources de l'implémentation, ce qui est un comportement indéfini. Dans le deuxième cas, une exception std::bad_alloc est levée, avec un comportement défini par la norme dans tous les cas.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bpdrjd$qit$2@news-reader5.wanadoo.fr>...
Nicolas Aunai wrote:
"Fabien LE LEZ" avait écrit le 17/11/2003 :
int x;
cin>>x;
int tab[x];
Ce n'est pas autorisé en C++ ; par contre il me semble que c'est
autorisé en C (sauf le 'cin' bien sûr).
en C99 oui, j'ai été très surpris de l'apprendre.
On peut par contre écrire :
int x;
cin>>x;
std::vector<int> tab (x);
oui ok, mais là vector s'occupe de la mémoire par derrière...
Bin, là le compilateur s'occupe de la mémoire par derrière. J'ai tu
mal à voir ce qui te gêne dans cet exemple.
Il y a quand même une différence importante entre :
int table[ n ] ;
et
std::vector< int > table( n ) ;
Dans le premier cas, s'il n'y a pas assez de mémoire, tu as épuisé les
ressources de l'implémentation, ce qui est un comportement indéfini.
Dans le deuxième cas, une exception std::bad_alloc est levée, avec un
comportement défini par la norme dans tous les cas.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Ce n'est pas autorisé en C++ ; par contre il me semble que c'est autorisé en C (sauf le 'cin' bien sûr).
en C99 oui, j'ai été très surpris de l'apprendre.
On peut par contre écrire :
int x; cin>>x; std::vector<int> tab (x);
oui ok, mais là vector s'occupe de la mémoire par derrière...
Bin, là le compilateur s'occupe de la mémoire par derrière. J'ai tu mal à voir ce qui te gêne dans cet exemple.
Il y a quand même une différence importante entre :
int table[ n ] ; et std::vector< int > table( n ) ;
Dans le premier cas, s'il n'y a pas assez de mémoire, tu as épuisé les ressources de l'implémentation, ce qui est un comportement indéfini. Dans le deuxième cas, une exception std::bad_alloc est levée, avec un comportement défini par la norme dans tous les cas.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
espie
In article , Nicolas Aunai ç wrote:
et bien par exemple, si on admet que le programmeur a pris TOUTES les sécurités possibles et imaginables pour controler les valeurs prises par x, il y a certains cas, par exemple dans des applications réseau, où x pourrait prendres des valeurs farfelues et imprévisibles venues de l'extérieur du programme... dans ces conditions, déclarer un tableau de dimension x, inconnue donc, me parait assez dangereux.
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
In article <mesnews.92927d3b.c7e943fd.269.1437@free.fr>,
Nicolas Aunai <nicolas.aunai@virerça@free.fr> wrote:
et bien par exemple, si on admet que le programmeur a pris TOUTES les
sécurités possibles et imaginables pour controler les valeurs prises
par x, il y a certains cas, par exemple dans des applications réseau,
où x pourrait prendres des valeurs farfelues et imprévisibles venues de
l'extérieur du programme... dans ces conditions, déclarer un tableau de
dimension x, inconnue donc, me parait assez dangereux.
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites,
et faire confiance a une valeur en provenance du reseau ?
et bien par exemple, si on admet que le programmeur a pris TOUTES les sécurités possibles et imaginables pour controler les valeurs prises par x, il y a certains cas, par exemple dans des applications réseau, où x pourrait prendres des valeurs farfelues et imprévisibles venues de l'extérieur du programme... dans ces conditions, déclarer un tableau de dimension x, inconnue donc, me parait assez dangereux.
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
Nicolas Aunai
"Marc Espie" avait écrit le 30/11/2003 :
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels engendrés par son propre code, c'est déjà je pense très dur, maintenant, dans une appli réseau, prévoir toutes les failles de sécurité est je pense quasi impossible... mais tout ceci est HS :)
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites,
et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels
engendrés par son propre code, c'est déjà je pense très dur,
maintenant, dans une appli réseau, prévoir toutes les failles de
sécurité est je pense quasi impossible... mais tout ceci est HS :)
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels engendrés par son propre code, c'est déjà je pense très dur, maintenant, dans une appli réseau, prévoir toutes les failles de sécurité est je pense quasi impossible... mais tout ceci est HS :)
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels engendrés par son propre code, c'est déjà je pense très dur, maintenant, dans une appli réseau, prévoir toutes les failles de sécurité est je pense quasi impossible... mais tout ceci est HS :)
HS? Pourquoi ?
Accessoirement, James t'a donne une des etapes sur cette longue route: l'utilisation d'assert, qui permet d'inserer dans le code les proprietes prouvees.
Cote securite reseau, comme dans la plupart des domaines, se limiter a des protocoles simples permet de limiter la casse. Ca veut dire entre autres qu'on construit par design des structures dont on est capable de verifier la coherence interne, ce qui evite les gags dont tu parles. Si tu ne peux pas verifier que la valeur de x est raisonnable, c'est que ton protocole est mal specifie, ou sous specifie.
Il y a egalement des gens qui etudient la specification formelle des protocoles reseaux. Ca ne debouche pas sur enormement d'applications pratiques dans l'immediat, mais a terme (sous cinq ans), ca a de fortes chances de nous donner des methodes d'expression un peu mieux adaptees a `la bonne' description de protocoles reseaux.
... Comme les invariants de boucles et autres assertions pour le code `classique'.
Le C++ est (a mon avis) en bonne place pour tout ce style de demarche, entre autres grace aux travaux de Sutter, Alexandrescu et autres qui mettent (entre autres) l'accent sur les moyens de ramener la verification dynamique du code a de la verification statique a la compilation.
In article <mesnews.f3967d3b.d1bf6760.305.1437@free.fr>,
Nicolas Aunai <nicolas.aunai@virerça@free.fr> wrote:
"Marc Espie" avait écrit le 30/11/2003 :
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites,
et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels
engendrés par son propre code, c'est déjà je pense très dur,
maintenant, dans une appli réseau, prévoir toutes les failles de
sécurité est je pense quasi impossible... mais tout ceci est HS :)
HS? Pourquoi ?
Accessoirement, James t'a donne une des etapes sur cette longue route:
l'utilisation d'assert, qui permet d'inserer dans le code les proprietes
prouvees.
Cote securite reseau, comme dans la plupart des domaines, se limiter a des
protocoles simples permet de limiter la casse. Ca veut dire entre autres
qu'on construit par design des structures dont on est capable de verifier
la coherence interne, ce qui evite les gags dont tu parles. Si tu ne
peux pas verifier que la valeur de x est raisonnable, c'est que ton
protocole est mal specifie, ou sous specifie.
Il y a egalement des gens qui etudient la specification formelle des
protocoles reseaux. Ca ne debouche pas sur enormement d'applications
pratiques dans l'immediat, mais a terme (sous cinq ans), ca a de fortes
chances de nous donner des methodes d'expression un peu mieux adaptees
a `la bonne' description de protocoles reseaux.
... Comme les invariants de boucles et autres assertions pour le code
`classique'.
Le C++ est (a mon avis) en bonne place pour tout ce style de demarche,
entre autres grace aux travaux de Sutter, Alexandrescu et autres qui
mettent (entre autres) l'accent sur les moyens de ramener la verification
dynamique du code a de la verification statique a la compilation.
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels engendrés par son propre code, c'est déjà je pense très dur, maintenant, dans une appli réseau, prévoir toutes les failles de sécurité est je pense quasi impossible... mais tout ceci est HS :)
HS? Pourquoi ?
Accessoirement, James t'a donne une des etapes sur cette longue route: l'utilisation d'assert, qui permet d'inserer dans le code les proprietes prouvees.
Cote securite reseau, comme dans la plupart des domaines, se limiter a des protocoles simples permet de limiter la casse. Ca veut dire entre autres qu'on construit par design des structures dont on est capable de verifier la coherence interne, ce qui evite les gags dont tu parles. Si tu ne peux pas verifier que la valeur de x est raisonnable, c'est que ton protocole est mal specifie, ou sous specifie.
Il y a egalement des gens qui etudient la specification formelle des protocoles reseaux. Ca ne debouche pas sur enormement d'applications pratiques dans l'immediat, mais a terme (sous cinq ans), ca a de fortes chances de nous donner des methodes d'expression un peu mieux adaptees a `la bonne' description de protocoles reseaux.
... Comme les invariants de boucles et autres assertions pour le code `classique'.
Le C++ est (a mon avis) en bonne place pour tout ce style de demarche, entre autres grace aux travaux de Sutter, Alexandrescu et autres qui mettent (entre autres) l'accent sur les moyens de ramener la verification dynamique du code a de la verification statique a la compilation.
kanze
Nicolas Aunai ç wrote in message news:...
"Marc Espie" avait écrit le 30/11/2003 :
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels engendrés par son propre code, c'est déjà je pense très dur, maintenant, dans une appli réseau, prévoir toutes les failles de sécurité est je pense quasi impossible...
Si tu utilises une valeur farfellue dans ton programme, c'est une erreur de programmation dans ton programme. Égal d'où vient la valeur ; un programme qui utilise des valeurs qui vient du reseau sans les valider est un programme erroné.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Nicolas Aunai <nicolas.aunai@virerça@free.fr> wrote in message
news:<mesnews.f3967d3b.d1bf6760.305.1437@free.fr>...
"Marc Espie" avait écrit le 30/11/2003 :
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les
securites, et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels
engendrés par son propre code, c'est déjà je pense très dur,
maintenant, dans une appli réseau, prévoir toutes les failles de
sécurité est je pense quasi impossible...
Si tu utilises une valeur farfellue dans ton programme, c'est une erreur
de programmation dans ton programme. Égal d'où vient la valeur ; un
programme qui utilise des valeurs qui vient du reseau sans les valider
est un programme erroné.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Il y a une grave contradiction elementaire dans ce que tu dis.
Comment est-ce que le programmeur peut avoir pris TOUTES les securites, et faire confiance a une valeur en provenance du reseau ?
par "TOUTES" les sécurités, je voulais dire tous les bugs éventuels engendrés par son propre code, c'est déjà je pense très dur, maintenant, dans une appli réseau, prévoir toutes les failles de sécurité est je pense quasi impossible...
Si tu utilises une valeur farfellue dans ton programme, c'est une erreur de programmation dans ton programme. Égal d'où vient la valeur ; un programme qui utilise des valeurs qui vient du reseau sans les valider est un programme erroné.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ
On 1 Dec 2003 00:03:32 -0800, wrote:
Égal d'où vient la valeur ; un programme qui utilise des valeurs qui vient du reseau sans les valider est un programme erroné.
D'ailleurs on a vite fait de passer plus de temps et de pondre plus de code pour la gestion des erreurs que pour le programme proprement dit...
-- ;-)
On 1 Dec 2003 00:03:32 -0800, kanze@gabi-soft.fr wrote:
Égal d'où vient la valeur ; un
programme qui utilise des valeurs qui vient du reseau sans les valider
est un programme erroné.
D'ailleurs on a vite fait de passer plus de temps et de pondre plus de
code pour la gestion des erreurs que pour le programme proprement
dit...
