fscanf ou fgets fait planter la fontion suivante

Version imprimable

10/09/2006, 15h19
copeau31

fscanf ou fgets fait planter la fontion suivante

bonjour a tous
j ai fait un prog ultra simpliste de lecture dans un fichier, et je me retrouve en tete a tete avec System.NullReferenceException...

----------------------------------------code----------
FILE * inifile;

if ((inifile = fopen("./clients.ini", "r")) == NULL)
return EXIT_FAILURE;

fscanf(inifile, "%d\n", &nb_clients);
clts = (char**)malloc(nb_clients*sizeof(char)*IPSIZE);
for (int i = 0 ; i < nb_clients ; i++)
fscanf(inifile, "%s\n", clts[i ]);
fclose(inifile);

----------------------------------------
sans la ligne en gras, tou marche impec'
avec cette ligne :

Exception non gérée : System.NullReferenceException: La référence d'objet n'est pas définie à une instance d'un objet.
at fclose(_iobuf* )
at main(Int32 argc, SByte** argv)

qqn a une idee ?
:? :roll:
10/09/2006, 15h36
Luc Hermitte

C'est quoi ton langage ?
L'exception à une tête de Java.
Les symtômes, c'est une lecture hors bornes/dans un endroit où rien n'a été alloué.
Le code a une tête de C où la mémoire n'a pas effectivement pas été allouée.
Le main a une signature des plus étranges.
Ce genre de lectures en C++ est bien plus simple à faire sans risquer de planter le programme quand on ne maitrise pas la gestion de la mémoire. Ce qui permet de se concentrer sur l'algorithmie dans un premier temps.

Il doit y avoir un exemple de lecture, en C++!, de fichiers ligne par ligne dans la FAQ.
10/09/2006, 15h42
copeau31

ben c du c++, meme si j'ai plus l habitude du c
et le malloc au milieu alloue bien la memoire (surdimensionnee, qui plus est)
sans compter que le fscanf marche (je les envoie sur std::cout et j ai tout ce qu'il faut)

c'est apres le fscanf qu il y a qqch de louche

j ai deja fait un tour sur la faq, je vais chercher plus....
merci
10/09/2006, 15h48
Jean-Marc.Bourguet

Citation:

Envoyé par Luc Hermitte

C'est quoi ton langage ?

<guess mode="educated">
C++/CLI
</guess>

Citation:

ben c du c++

Non, c'est du C compilé avec un compilateur C++/CLI.

Et C++ est un langage différent de C et de C++/CLI.

Ton code C est mauvais, mais si tu veux la bonne solution C il faut aller dans le forum C.
Voici la solution C++ :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #include <fstream> #include <vector> #include <string> std::ifstream inifile("./clients.ini"); int nb_clients; inifile >> nb_clients; std::vector<std::string> clts(nb_clients); for(int i=0; i<nb_clients; i++) { std::getline(inifile, clts[i]); }

10/09/2006, 17h44
copeau31

merci loufoque, j en etais arrive la, avec un tableau bien moins propre.

mtn j ai plein de fonctions qui ont des char* en parametres et moi je me retrouve avec des strings...

y a-t- il une convertion evidente ?
(pas envie de me taper ttes les fonctions)

edit: c bon pour ca, jairetrouve c_str()

merci pour tout
10/09/2006, 19h05
Luc Hermitte

Ton alloc n'est pas bonne. Si tu veux un tableau de chaînes, il faut bien plus de manipulations que cela.
11/09/2006, 14h26
homeostasie

Citation:

Si tu veux un tableau de chaînes, il faut bien plus de manipulations que cela.

Pas forcément mais dans le cas présenté, c'est pas comme cela qu'il fait faire! ;)
Puis transtyper en char** le retour du malloc me semble plutot bizarre...De plus, le transtypage char* n'est pas obligatoire, du moins en C car c'est implicite, en C++, non!
Il y a deux manières de représenter un tableau de chaînes, je te laisse voir ce lien:
http://c.developpez.com/faq/c/?page=...bleau_2D_alloc
11/09/2006, 22h25
Luc Hermitte

Pour un tableau de chaines de la sorte, il faut obligatoirement une structure intermédiaire d'indirection. Dans tous les cas, il manque soit une double série d'allocation, soit une seule allocation suivie de la construction de la table d'index intermédiaires pour chaque chaîne rentrée.
Bref, il manque quelque chose.
Accessoirement, le code de la FAQ C est incorrect dans la mesure où il ne vérifie nulle part si les allocations se déroulent correctement.

Code:

1 2 3 4 5 6 7 8 9 10 FILE * inifile; if ((inifile = fopen("./clients.ini", "r")) == NULL) return EXIT_FAILURE; fscanf(inifile, "%d\n", &nb_clients); clts = (char**)malloc(nb_clients*sizeof(char)*IPSIZE); for (int i = 0 ; i < nb_clients ; i++) fscanf(inifile, "%s\n", clts[i ]); fclose(inifile);
Le problème est que tu as bien créé dynamiquement le tableau de pointeur sur char, mais tu n'as pas alloué de mémoire pour chacun de ses éléments (chaque élément doit être un pointeur sur char). Donc ta (deuxième) fonction fscanf essaye d'écrire dans des zones indeterminées de la mémoire, d'où plantage.

Un petit truc aussi. Concernant la ligne

Code:

clts = (char**)malloc(nb_clients*sizeof(char)*IPSIZE);

J'aurais plutôt écrit un truc du genre :

Code:

clts = (char**)malloc(nb_clients*sizeof(char*));

12/09/2006, 14h03
homeostasie
Citation:

Accessoirement, le code de la FAQ C est incorrect dans la mesure où il ne vérifie nulle part si les allocations se déroulent correctement.

C'est vrai! ;)

Citation:

J'aurais plutôt écrit un truc du genre :

Code:

clts = (char**)malloc(nb_clients*sizeof(char*));

Pas tout à fait, ca donne toujours l'impression qu'il manque quelque chose. Sourire. Tu réserves un tableau de N pointeurs sur char* mais les pointeurs ne pointent sur aucune chaine de caractères...

Dans le cas d'une simple allocation dynamique, il est préférable de faire ainsi:
Code:

1 2 char* clts = malloc(nb_clients*sizeof(*clts));
Mais ce n'est pas ce qui est recherché ici.
12/09/2006, 19h10
Luc Hermitte

Note au sujet du dernier code donné par Jéroman.
Il s'agit de la solution type en C pour fainéants, le genre que l'on voit en cours, et qui causera des dégats en production sur les cas aux limites -- le genre qui se conclu par des patchs de sécurité sur divers logiciels

J'y reproche :
- une non gestion des erreurs d'allocation qui peuvent survenir
- des débordements de buffers potentiels
- une ergonomie d'un autre âge : les chaînes auront une taille limite

La solution type, équivalente, en C++ pour fainéants ne présente aucun de ces défauts. Et en plus, le code utilisateur est bien plus court, et plus simple à maintenir.
12/09/2006, 20h41
jeroman

Citation:

Dans le cas d'une simple allocation dynamique, il est préférable de faire ainsi:

Citation:

char* clts = malloc(nb_clients*sizeof(*clts));

Mais ce n'est pas ce qui est recherché ici.

Pourtant, si j'ai bien tout compris, il s'agissait de créer dynamiquement un tableau contenant lui-même plusieurs chaînes de caractères.
En solution C, il s'agit donc bien de créer un tableau de pointeur sur char (char** et non char*). Puis ensuite, de créer dynamiquement des tableaux de char (char*) et de remplir chacun des éléments du tableau "clts" avec la valeur retournée par les malloc() correspondant à chacune de ces chaînes.
Dans ton exemple, tu créés non pas un tableau de pointeur sur char (char**), mais un tableau de char (char*).
A moins que j'ai mal compris l'histoire ? :lol:

Citation:

Note au sujet du dernier code donné par Jéroman.
Il s'agit de la solution type en C pour fainéants, le genre que l'on voit en cours, et qui causera des dégats en production sur les cas aux limites -- le genre qui se conclu par des patchs de sécurité sur divers logiciels

J'y reproche :
- une non gestion des erreurs d'allocation qui peuvent survenir
- des débordements de buffers potentiels
- une ergonomie d'un autre âge : les chaînes auront une taille limite

La solution type, équivalente, en C++ pour fainéants ne présente aucun de ces défauts. Et en plus, le code utilisateur est bien plus court, et plus simple à maintenir.

Oui, je ne suis pas hyper calé en C/C++ (j'y touche de temps en temps). Je voulais simplement expliquer le pourquoi du plantage dans le code d'origine et donner une idée de résolution du problème (comme le code était en C, j'ai "corrigé" en code C).
12/09/2006, 20h44
Luc Hermitte

(C != C++)
La correction n'est que partielle : il reste des problèmes dormants.

Citation:

Pourtant, si j'ai bien tout compris, il s'agissait de créer dynamiquement un tableau contenant lui-même plusieurs chaînes de caractères.En solution C, il s'agit donc bien de créer un tableau de pointeur sur char (char** et non char*)

Oui, c'est bien cela. ;)

Citation:

Dans ton exemple, tu créés non pas un tableau de pointeur sur char (char**), mais un tableau de char (char*).

Oui, dans mon exemple, c'est un tableau de char.

En fait j'ai fait cela pour bien distinguer ceci

Code:

char* clts = malloc(nb_clients*sizeof(*clts));

à cela:

Code:

clts = (char**)malloc(nb_clients*sizeof(char*));

qui pour ma part n'est pas vraiment correct...D'ailleurs Luc Hermitte te fait partager son avis.
Un code plus correct, magré qu'il n'y a pas de vérification concernant si l'allocation a réussi, serait:
Code:

1 2 3 4 5 6 7 8 9 10 char **tab; /* Allocation de la 1er dimension */ tab = malloc ( sizeof(*tab) * taille); /* Allocation des tableaux */ for (i=0; i<taille; i++) { tab[i] = malloc ( sizeof(**tab) * taille2); }
Citation:

(C != C++)

Oh oui...:)

Ce qu'a fait loufoque semble être bien pour ce qui est de réaliser ce code en c++, non?

Citation:

Envoyé par homeostasie

Code:

clts = (char**)malloc(nb_clients*sizeof(char*));

qui pour ma part n'est pas vraiment correct...D'ailleurs Luc Hermitte te fait partager son avis.

Je n'avais même pas pris la peine de regarder si cet appel était bon ou pas -- et je ne compte pas non plus maintenant faire travailler mes neurones sur cette question. Au pire, ce n'est que de la syntaxe et des fonctions affines à corriger. Rien d'important. La façon dont la mémoire est gérée est une chose bien plus importante.

Citation:

Ce qu'a fait loufoque semble être bien pour ce qui est de réaliser ce code en c++, non?

Je m'y serais pris légèrement différemment pour gérer les fichiers mal formés
Code:

1 2 3 4 5 6 7 8 9 10 11 int nbclients; if (fichier >> nbclients) { clients.reserve(nbclients); // optimisation facultative std::string ligne; while (std::getline(fichier, ligne)) clients.push_back(ligne)); if (nbclients != clients.size()) throw .... } else { throw ... };