Discussion :

[ethan007]

Bonsoir à tous, je fais un projet et je viens de rencontrer un petit disfonctionnement je cherche des explications...
J'ai un fichier qui contient la définiton d'une matrice (en première ligne du fichier on a le nombre de ligne et le nombre de colonne (de la matrice), puis la suite c'est la matrice elle même)
EX:
3 3
1 2 3
4 5 6
7 8 9

Mon but est d'écrire une fonction qui lit le contenu du fichier et renvoie tous ce contenu (y compris la première ligne) sous forme de char* et voici mon code (qui fonctionne..fin je pense):
gestion_fichiers.c

Code c :

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
26
27
28
29
30
31
32
33
34
35
36
37
38
 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "gestion_fichiers.h"
 
char *lire_fichier(char *nom_fichier){
    FILE *fichier = fopen(nom_fichier, "r");
    int nbreL = fgetc(fichier);
    nbreL = (int)nbreL - '0';//cast
    fgetc(fichier); //Espace entre le nombre de lignes et le nombre de colonnes au début du fichier
    int nbreC = fgetc(fichier);
    nbreC = (int)nbreC - '0';//cast
 
    int taille_ligne = nbreC + (nbreC -1);//La taille de la ligne à lire se calcule en incluant les espaces, pour n colonnes il y a n-1 espaces
    char *current_line_data = (char*)malloc(nbreC * sizeof(char));
    char *file_data = (char*)malloc(nbreC * nbreL * sizeof(char)+3); //will store the retrieved data # +3 is the nbreL space and nbreC
    printf("L = %d et C = %d", nbreL, nbreC);
    fseek(fichier, 0, SEEK_SET);//Get the cursor back to first ligne
    strcat(file_data, fgets(current_line_data, 4, fichier));//La première ligne du fichier
 
    if(fichier != NULL){
        while(fgets(current_line_data, taille_ligne +1, fichier)){
 
            strcat(file_data, current_line_data);//We are sure the space is enough for all datas because we calculated it earlier
        }
    }else{
        printf("The file %s doest not exist! exiting...", nom_fichier);
        exit(1);//Error can be handleled
    }
 
    free(current_line_data);
    return file_data;
}
 
void desallouer_donnees_fichier(char *ptr_datas){
    free(ptr_datas);
}

le .h:
gestion_fichiers.h

Code c :

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

1
2
3
4
5
 
#include <stdio.h>
#include <stdlib.h>
char *lire_fichier(char *nom_fichier);
void desallouer_donnees_fichier(char *ptr_datas);

Dans le main j'appelle ma fonction avec le code suivant:
main.c:

Code c :

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
 
#include <stdio.h>
#include <stdlib.h>
#include "gestion_fichiers.h"
 
int main(){
 
 
printf("\n-----------GESTION DU FICHIER!-------\n");
	char *donnees = lire_fichier("file.txt");
	printf("Affichage des données:\n %s", donnees);
	printf("\n-----------AUREVOIR !-------\n");
 
	//desallouer_matrice(mat);
	//desallouer_matrice(produit);
	desallouer_donnees_fichier(donnees);
	return 0;
}

Ce code marche bien mais lorsque je déboguait ailleurs j'ai constaté que la ligne 16 du fichier "gestion_fichiers.c" n'alloue pas un tableau de char de taille nbreC * sizeof(char)
En réalité j'a remplacé cette ligne par:

Code c :

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

1
2
 
char *current_line_data = (char*)malloc(1);

qui normalement devrait allouer 1 octet, ce qui devait me faire apparaitre une belle érreur de ségmentation (mon ami de tous les jours :p) à la ligne 24 mais au contraire tous ce passe bien : je me demande donc est ce que le fait que j'ai utilisé un malloc ou fgets le pousse recalculer la nouvelle taille à chaque tour de la boucle qui est à la lgine 24???

Best regards.

[Bousk]

Donc tu veux juste lire un fichier et stocker son contenu dans un char* ?
fopen
fseek
ftell
rewind
fread

[ethan007]

Bonsoir merci pour cette réponse rapide, en fait j'ai oublié de dire que c'est un projet d'école et les contraintes c'est d'utiliser uniquement fgets pour renvoyer le char*.
or fgets en boucle écrase à chaque itération.

[dalfab]

Bonjour,

Ligne 16, tu n'alloues pas assez de caractères, il faut aussi réserver de la place pour le terminateur et le caractère de retour chariot.
Ligne 17, je n'ai refait le calcul. Mais j'ai de gros doutes sur le nombre réservé.
Ligne 20, tu concatènes dans file_data, donc tu supposes qu'initialement elle est vide, mais où est-ce fait? Et pire qu'y a-t-il dans current_line_data? On n'y a jamais rien mis.

Maintenant pourquoi 1 semble suffire ligne 16? Si on n'alloue pas pas assez de place on a un "undefined behavior", ce qui veut dire que tout est possible et en particulier cela peut sembler fonctionner. Les caractères en trop se retrouvent dans un endroit non réservé, non prévu qui peut casser une autre partie du logiciel. Pour certains compilateurs quand on demande 1 octet on en obtient parfois 7 de plus en "cadeau", c'est ce qui doit ce passer dans ton cas.

[ethan007]

Bonsoir

Bonjour,

Ligne 16, tu n'alloues pas assez de caractères, il faut aussi réserver de la place pour le terminateur et le caractère de retour chariot.

Exact, merci

Ligne 17, je n'ai refait le calcul. Mais j'ai de gros doutes sur le nombre réservé.

En effet j'aurai dû penser aux espaces

Ligne 20, tu concatènes dans file_data, donc tu supposes qu'initialement elle est vide, mais où est-ce fait?

Bon je devrait lui affecter NULL avant de faire le malloc?

Et pire qu'y a-t-il dans current_line_data? On n'y a jamais rien mis.

current_line_data est rechargé à chaque tour de boucle while(gets..) de la ligne 23

Maintenant pourquoi 1 semble suffire ligne 16? Si on n'alloue pas pas assez de place on a un "undefined behavior", ce qui veut dire que tout est possible et en particulier cela peut sembler fonctionner. Les caractères en trop se retrouvent dans un endroit non réservé, non prévu qui peut casser une autre partie du logiciel. Pour certains compilateurs quand on demande 1 octet on en obtient parfois 7 de plus en "cadeau", c'est ce qui doit ce passer dans ton cas.

Ah soulagement je cherchait une explication là dessus, c'est donc peu être le fameux "undefined behavior" qui a de la chance d'aller dans des blocs inutilisés..
[/QUOTE]

Pour certains compilateurs quand on demande 1 octet on en obtient parfois 7 de plus en "cadeau", c'est ce qui doit ce passer dans ton cas

mais pourquoi est ce que le compilateur devrait allouer ne serait-ce que 1 octet de plus alors que j'en ai demandé un nombre exact? imaginons un programmeur sur un carte avec quelques Ko..

[Kannagi]

mais pourquoi est ce que le compilateur devrait allouer ne serait-ce que 1 octet de plus alors que j'en ai demandé un nombre exact? imaginons un programmeur sur un carte avec quelques Ko..

Cela n'est pas à cause de ton compilateur mais de ton processeur et c'est ce qu'on appelle l'alignement.

Sur une machine de quelque ko , les contraintes ne sont pas les mèmes et donc un processeur 8 bits n'a aucune mal a gérer la mémoire si elle n'est pas aligné.
(Mais si tu as vraiment besoin d'économiser la mémoire jusqu'a ce que la pile te pose souci , alors tu peux aller en assembleur).

[chrtophe]

Cela n'est pas à cause de ton compilateur mais de ton processeur et c'est ce qu'on appelle l'alignement.

Oui, mais rien n'empêche le compilateur de rajouter des octets. C'est notamment le cas avec la stack smashing protection de gcc, qui va aussi ajouter un canari pour se protéger d'une corruption de pile. Il doit y avoir le même système sous Windows.

Pour ceux qui ne le savent pas, le canari est une valeur qui sert à vérifier que la pile n'a pas été corrompue, c'est utilisé par le système de prologue/épilogue des fonctions.
Le terme canari est utilisé en référence aux canaris utilisés dans les mines de charbon. Quand le canari ne chantait plus, un coup de grisou était probable et la mine était évacuée.

[dalfab]

Bon je devrait lui affecter NULL avant de faire le malloc?

Avant malloc!

Code :

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

1
2
3
4
5
6
7
8
// que fait ce code ?
char *current_line_data = "hello";
current_line_data = NULL;
current_line_data = malloc(nbreC +2);
// ou, même question, que fait ce code ?
double a = 3.14159;
a = 0;
a = 5 * 3;

Après malloc, on peut initialiser le 1er caractère à '\0' ou commencer par strcpy() plutôt qur strcat().

current_line_data est rechargé à chaque tour de boucle while(gets..) de la ligne 23

Et par quelle magie, en ligne 20 c'est déjà rempli?

mais pourquoi est ce que le compilateur devrait allouer ne serait-ce que 1 octet de plus alors que j'en ai demandé un nombre exact? imaginons un programmeur sur un carte avec quelques Ko..

J'ajoute aux réponses précédentes que sur les cartes avec quelques Ko (c'est mon métier) on n'alloue jamais rien saufs de rares grands blocs (c-a-d quelques centaines d'octets), la perte relative est donc négligeable.

[ethan007]

Et par quelle magie, en ligne 20 c'est déjà rempli?

La fonction fgets copie le flux lu dans le chaine passée en paramètre donc même si il y a déja quelque chose, cette chose est écrasée..non?

Cela n'est pas à cause de ton compilateur mais de ton processeur et c'est ce qu'on appelle l'alignement.

Sur une machine de quelque ko , les contraintes ne sont pas les mèmes et donc un processeur 8 bits n'a aucune mal a gérer la mémoire si elle n'est pas aligné.
(Mais si tu as vraiment besoin d'économiser la mémoire jusqu'a ce que la pile te pose souci , alors tu peux aller en assembleur).

Ah ce fameux alignement je pense que tu répond à la principale question du sujet.

peu être le sujet est RESOLU+1

[Sve@r]

Bonjour

La fonction fgets copie le flux lu dans le chaine passée en paramètre donc même si il y a déja quelque chose, cette chose est écrasée..non?

Le souci ne vient pas de fgets() mais de strcat(). Car l'élément sur lequel tu l'appliques n'est pas une chaine. C'est un simple pointeur alloué et non initialisé.

Reprenons la base: la fonction strcat(str1, str2) va concaténer str2 à la suite de str1. Donc elle commence par se placer à la fin de str1 pour y rajouter str2. Mais pour trouver la fin de str1, elle se base sur le '\0' sensé s'y trouve.
Si str1 n'est pas une chaine, alors il n'a pas de '\0' et donc strcat() ne peut pas se caler dessus.

Donc 2 façons de faire

1. tu garantis que str1 (ici file_data) est bien une chaine en lui mettant un '\0' à la main (ex file_data[0]='\0'). C'est parfaitement autorisé et ça fonctionne. Ensuite tu peux y faire du strcat() autant que tu voudras
2. tu ne lui fais pas une concaténation mais une initialisation (ex strcpy(file_data, fgets(...)).

Bref en résumé tu t'arranges pour que file_data soit une chaine avant de lui appliquer la moindre opération sous-entendant une lecture de chaine.

mais pourquoi est ce que le compilateur devrait allouer ne serait-ce que 1 octet de plus alors que j'en ai demandé un nombre exact? imaginons un programmeur sur un carte avec quelques Ko..

Optimisation. Tu demandes 1 et le truc t'en alloues un gros stock pour pas appeler le lourd mécanisme d'allocation pour presque rien. T'as la fonction getpagesize() qui donne la taille d'une page mémoire (chez-moi 4096). Généralement, une allocation de "n" se traduira par une allocation de "m" ("m" étant le plus petit nombre supérieur ou égal à "n" et multiple entier d'une taille de page). Ensuite, si tu agrandis la zone de "n" à "n2" mais que "n2" reste inférieur à "m", le bouzin se contente de déplacer un flag mais sans tout remettre en branle.
Mais que cela ne t'empêche pas de bien gérer ton besoin. Si tu as besoin de 5, tu alloues 5 et pas 1 en te disant "bof de toute façon j'aurai 4096".

Toutefois tu dois bien sentir qu'une allocation de "1" c'est un peu ridicule. Donc tu peux toi-aussi définir ton propre mécanisme de bufferisation. Style tu alloues 256 (même si tu n'as besoin que de 5) mais tu mémorises la taille allouée et la taille utilisée. Ensuite, quand ton truc grandis, tu déplaces la taille utilisée et si celle-ci atteint la taille allouée, alors là seulement tu agrandis.

Petit exemple d'allocation en fonction du besoin

Code c :

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
typedef struct {
	char *zone;
	char *tmp;
	size_t alloue;
	size_t rempli;
} t_memory;
 
t_memory buffer;
buffer.zone=NULL;
buffer.alloue=0;
buffer.rempli=0;
 
while (lecture(info)) {
	// Vérification besoin agrandissement buffer
	if (buffer.alloue == buffer.rempli) {
		// Agrandissement
		buffer.alloue+=N
		buffer.tmp=realloc(buffer.zone, buffer.alloue * sizeof(char));		// Si la zone est à NULL, realloc se comporte comme malloc
 
		// Echec allocation ?
		if (buffer.tmp == NULL) {
			// Gestion du problème (généralement libération et sortie)
			free(buffer.zone);			// Heureusement que je n'ai pas perdu "zone" (cette ligne est la seule et unique raison d'exister de "tmp") !!!
			return ...;
		}
 
		// Ici le buffer temporaire a été agrandi (ou alloué à la première itération) - On le récupère dans la zone
		buffer.zone=buffer.tmp;
	}
 
	// Ici, soit on est passé dans le "if" soit on n'y est pas passé mais dans les deux cas on est certain d'avoir la place pour y stocker l'information lue
	// Et cette information sera bien évidemment stockée à l'index de remplissage actuel
	buffer.zone[buffer.rempli]=info;
 
	// On a rempli une info de plus
	buffer.rempli++;
}
 
// Ici, "buffer.rempli" contient le nombre réel d'info contenues dans la zone, et "buffer.alloue" contient la taille allouée
...		// Il n'y a plus qu'à traiter...

Ensuite, te suffit de définir N à ton choix pour moduler cet algorithme en fonction de ta machine cible.

[ethan007]

Bonjour

...
....
Petit exemple d'allocation en fonction du besoin

Code c :

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
26
27
28
29
30
31
32
33
34
35
36
37
typedef struct {
	char *zone;
	char *tmp;
	size_t alloue;
	size_t rempli;
} t_memory;
 
t_memory buffer;
buffer.zone=NULL;
buffer.alloue=0;
buffer.rempli=0;
 
while (lecture(info)) {
	// Vérification besoin agrandissement buffer
	if (buffer.alloue == buffer.rempli) {
		// Agrandissement
		buffer.alloue+=N
		buffer.tmp=realloc(buffer.zone, buffer.alloue * sizeof(char));		// Si la zone est à NULL, realloc se comporte comme malloc
 
		// Echec allocation ?
		if (buffer.tmp == NULL) {
			// Gestion du problème (généralement libération et sortie)
			free(buffer.zone);			// Heureusement que je n'ai pas perdu "zone" (cette ligne est la seule et unique raison d'exister de "tmp") !!!
			return ...;
		}
 
		// Ici le buffer temporaire a été agrandi (ou alloué à la première itération) - On le récupère dans la zone
		buffer.zone=buffer.tmp;
	}
 
	// Ici, soit on est passé dans le "if" soit on n'y est pas passé mais dans les deux cas on est certain d'avoir la place pour y stocker l'information lue
	// Et cette information sera bien évidemment stockée à l'index de remplissage actuel
	buffer.zone[buffer.rempli]=info;
 
	// On a rempli une info de plus
	buffer.rempli++;
}

......
.......

Parfait, c'est fou cette histoire de mémoire. là je comprend pourquoi mon code faisait un peu du n'importe quoi. MERCI