Discussion :

[dmichel]

Bonjour a tous,

voila, j'ai cree un petit parser de commande, modeste et pas parfait mais suffisant pour mes besoins....

il fonctionne correctement mais cree un bug assez bizarre : les allocations memoires dynamiques, que j'effectue apres, plantent.
Les variables utilisees pour ces allocations n'ont apparement aucun lien avec le parser. Cependant, si j'ote le parser, tous va bien.... bizarre

encore plus bizarre, le code fonctionne parfaitement sous linux. sous windows avec devcpp..bug.

voici un code minimal qui demontre le probleme

merci d'avance pour votre aides

Dav

[Thierry Chappuis]

Bonjour a tous,

voila, j'ai cree un petit parser de commande, modeste et pas parfait mais suffisant pour mes besoins....

il fonctionne correctement mais cree un bug assez bizarre : les allocations memoires dynamiques, que j'effectue apres, plantent.
Les variables utilisees pour ces allocations n'ont apparement aucun lien avec le parser. Cependant, si j'ote le parser, tous va bien.... bizarre

encore plus bizarre, le code fonctionne parfaitement sous linux. sous windows avec devcpp..bug.

voici un code minimal qui demontre le probleme

merci d'avance pour votre aides

Dav

Salut,

Je n'ai pas regardé en détail, mais c'est pas beau à voir. Outre l'inclusion de l'en-tête iostream qui n'existe pas en C et les casts de calloc() qui sont déconseillés, je vois:

• Des variables globales: en as-tu réellement besoin?
• Que fait ta fonction allocationmem(), à part générer des trous de mémoire, parce que là, je vois pas? ())

De manière générale, tu ne vérifies jamais la valeur de retour de tes fonctions d'allocation dynamique. C'est une grosse erreur, tu devrais toujours le faire...

Thierry

[souviron34]

et c'est passé à la compile ça ???? sous Linux ????

je te crois pas...

Au moins 2 énormités qui ne passent pas :

Code :

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

1
2
3
4
 
 Opt_name[0] = "-h";
 Opt_name[1] = "-c";
 Opt_name[2] = "-p";

et

Code :

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

1
2
 
           Opt_data[j] = cmd_v[i+k+1];

Les chaînes de caractères ne se copient pas comme ça, en C...

Il faut utiliser un strcpy, ou un strdup...

Comme tu as déjà alloué la mémoire, ça sera strcpy :

Code :

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

1
2
3
4
 
strcpy( Opt_name[0], "-h");
strcpy( Opt_name[1], "-c");
strcpy( Opt_name[2], "-p");

et

Code :

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

1
2
 
           strcpy (Opt_data[j], cmd_v[i+k+1]);

[dmichel]

oups...j'avais pa fais gaffe a l'en-tête iostream...

mais a part ca...oui le code est assez brouillon avec des variable globales, etc...
mais ca n'explique pas le probleme ! La fonction allocationmem() ne fait rien en effet....car c'est juste un example !

Pourquoi est-ce que ca plante avec le parser ? pourquoi ca passe sans le parser?

sinon, ca compile sans problemes sous linux (as-tu essaye au moins ?)
et je vois pas le probleme avec

Code :

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

Opt_name[0] = "-h"

Du moment que Opt_name est definie comme

Code :

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

 char **Opt_name

[Trap D]

Il n'y a aucun problème à faire

Code :

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

Opt_name[0] = "-h"

sauf que tu as une fuite de mémoire puisqu'avant tu as alloué de la mémoire à Opt_name[0].
J'ai regardé ton code, à quoi sert cette fonction

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
void allocationmem(int bla)
{
 
int *gb_type,*gb_line,*gb_fill,*gb_trans,*gb_orient;
int *gb_type_old,*gb_line_old,*gb_fill_old,*gb_trans_old,*gb_orient_old;
int *gb_type_left,*gb_type_right;
 
printf("allocation...\n");
 
       gb_type = (int*)calloc(bla,sizeof(int));
       gb_fill = (int*)calloc(bla,sizeof(int));
       gb_line = (int*)calloc(bla,sizeof(int));
       gb_trans = (int*)calloc(bla,sizeof(int));
       gb_orient = (int*)calloc(bla,sizeof(int));
       gb_type_old = (int*)calloc(bla,sizeof(int));
       gb_fill_old = (int*)calloc(bla,sizeof(int));
       gb_line_old = (int*)calloc(bla,sizeof(int));
       gb_trans_old = (int*)calloc(bla,sizeof(int));
       gb_orient_old = (int*)calloc(bla,sizeof(int));
       gb_type_left = (int*)calloc(bla,sizeof(int));
       gb_type_right = (int*)calloc(bla,sizeof(int));
 
printf("allocation terminated\n");
 
}/*end function*/

Puisque tu alloues des variables qui ne sont pas utilisées ensuite ?

[souviron34]

Il n'y a aucun problème à faire

Code :

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

Opt_name[0] = "-h"

EN C ?????????????

que je sache "-h" est une chaîne de caractères, pas un caractère..

Et en C, la copie/assignation de chaîne se fait par strcpy..

[dmichel]

"-h" est en effet une chaine de character...c'est pour ca que Opt_name est un double pointer !! char **Opt_name ...c'est pas pareil que char Opt_name !!!

Bref, la question n'est pas la... la fonctione allocationmem() ne sert a rien dans cet example, c'est vrai. C'est juste un example. J'ai retire la suite du code pour que ca soit plus simple a lire.

mais il y a un test simple a faire....runner le code tel quel et runner le code sans la fonction custom_parser(). Voyez la difference...

avec la fonction custom_parser(), le code se plante dans allocationmem() et ne va pas jusqu'au bout (l'inscription "allocation terminated" ne s'affiche pas).

[Trap D]

Opt_name est de type char **, donc Opt_name[0] est de type char *.
[Edit] j'ai testé le code sous Vista avec Visual Studio 2005 pas de problème de plante.
[/edit]

[souviron34]

et alors ?

ça marche bien dans son code il fait :

Code :

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

1
2
3
4
5
 
 Opt_name = (char**)calloc(Num_opts,sizeof(char*));
 for(i=0;i<Num_opts;i++){
 Opt_name[i] = (char*)calloc(10,sizeof(char));
 }

JE MAINTIENS LE strcpy ...............

[Trap D]

Nous sommes bien d'accord qu'il y a une fuite mémoire, mais on peut effectivement faire Opt_name[0] = "-h" (c'est une co***rie je te l'accorde )

Il a oublié aussi dans son code tous les free, c'est très mal programmé mais il n'y a pas de plante.

[dmichel]

j'ai testé le code sous Vista avec Visual Studio 2005 pas de problème de plante.

Haha...car sous WinXP avec devcpp, ca plante. J'ai d'abord pense que le compilateur en avait un coup dans le nez...alors j'ai deinstalle et reinstalle devcpp, mais la meme chose se produit. Sous linux, pas de problemes.

[dmichel]

Nous sommes bien d'accord qu'il y a une fuite mémoire, mais on peut effectivement faire Opt_name[0] = "-h" (c'est une co***rie je te l'accorde )

Comme je l'ai dis precedemment...c'est un brouillon

Il a oublié aussi dans son code tous les free, c'est très mal programmé mais il n'y a pas de plante.

j'ai enleve beaucoup du reste du code pour simplicite.... mais apparement, ca prete a confusion... desole.

Mais comme tu l'as dis...c'est mal ecrit, mais ca devrait pas plante pour autant...

il faudrait que quelqu'un avec Devcpp essaye

[souviron34]

Nous sommes bien d'accord qu'il y a une fuite mémoire, mais on peut effectivement faire Opt_name[0] = "-h" (c'est une co***rie je te l'accorde )
.

Je ne crois pas. Ce n'est pas une initialisation dans une déclaration. C'est en cours d'exécution. Et je met ma main à couper que tout ce que ça fait, c'est mettre une adresse dans Opt_name[0][0] , ou à la limte le caractère '-'. Sans plus.

[dmichel]

Et je met ma main à couper que....

c'est dommage, j'ai pas de hache

si tu essayais le code, tu verrais qu' il n'y a pas de problemes

[souviron34]

1) ce n'est pas parce qu'il n'y a pas de problème que ça marche
2) yen a ben un, problème, puisque tu plantes..

c'est juste que ça dépend des tolérances et des environnements.

[dmichel]

selon moi, Opt_name[0][0] aura le character "-" et Opt_name[0][1] aura "h"
en tous cas c'est ce que je veux avoir....ok il y aura une fuite de memoire car l'allocation memoire precedent permet 10 characters

et donc, selon toi, ca causerait le plantage dans les callocs comme celui ci

gb_orient = (int*)calloc(bla,sizeof(int));


....mmmm, la je vois pas...faut m'expliquer

[souviron34]

je répète juste que la manière correcte (indépendamment de ce qu'en fait le compilo ou le RAD), en C, de copier une chaîne est strcpy...

[dmichel]

ok...il faut que j'essaye ca. Mais la je suis sur linux au boulot donc j'essayerais ce soir

[droggo]

Hoal,

Haha...car sous WinXP avec devcpp, ca plante. J'ai d'abord pense que le compilateur en avait un coup dans le nez...alors j'ai deinstalle et reinstalle devcpp, mais la meme chose se produit. Sous linux, pas de problemes.

Avant de penser ce genre de truc, il faut faire du code propre et, au minimum, correct.

Je ne doute pas que tous les compilateurs aient quelques petits bugs de-ci de-là, mais avant d'accuser ton compilateur, il faut.... retour au 1er paragraphe.

[Trap D]

Je ne crois pas. Ce n'est pas une initialisation dans une déclaration. C'est en cours d'exécution. Et je met ma main à couper que tout ce que ça fait, c'est mettre une adresse dans Opt_name[0][0] , ou à la limte le caractère '-'. Sans plus.

Opt-name[0] étant un pointeur vers une chaîne de caractères, qu'il soit initialisé par un malloc ou par l'adresse d'une chaîne codée en dur en mémoire, je ne vois pas où est le problème.
Son programme plante peut-être à cause de cette manipulation Opt_data[j] = cmd_v[i+k+1]; un peu bizarre dont je viens de m'apercevoir et qui avec cette combiansion d'arguments doit donner des résultats incorrects.