malloc & characteres speciaux

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour,
Je suis occupé de développer une petite application de recherche rapide pour retrouver des id, pseudo,... de joueurs que je stock dans un fichier.

Pour ce faire j'ai fais 2 structures
Code:

1 2 3 4 5 6 struct user{ int server; int id; char pseudo[30]; char pseudo_ingame[30]; };
Code:

1 2 3 4 5 struct index{ struct user user; struct index *suivant; };
J'essaye de faire un syteme avec allocation dynamique
Code:

1 2 struct index *p14; UpdateIndexFichier(FICHIER14, &p14);
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 bool UpdateIndexFichier(char* Adress, struct index **pIndex) { FILE *fichier; bool status = false; if((status = TestFile(Adress))){ if((fichier = fopen(Adress, "rb"))){ *pIndex = LoadUsers(fichier); printf("%d\n", *pIndex->user.server); fclose(fichier); }else printf("ERREUR lors de l'ouverture du fichier %s\n", Adress); }else printf("Maj Index impossible: Ouverture de fichier impossible\n"); return status; }
Code:

printf("%d\n", *pIndex->user.server);

Pourquoi le compilateur crie-t-il? comment résoudre?
Code:

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 struct index* LoadUsers(FILE *fichier) { struct index tmpIndex, *start = NULL; struct user *user; //fread(&tmpIndex.user, sizeof(tmpIndex.user), 1, fichier); tmpIndex.user.server = 14; tmpIndex.suivant = NULL; start = (struct index*)malloc(sizeof(tmpIndex)); if(start){ start = &tmpIndex; if(DEBUG) printf("Malloc créé: adresse: %d", start); } else printf("erreur lors de la création de mise en mémoire\n"); /* while(!feof(fichier)){ for(cpt ) }; */ return start; }
Avec ce que je viens de vous donner petite question =>
Comment puis-je vérifier que le malloc c'est bien passé? Puis-je de manière portable récupérer ça taille ? (D'apres mes recherches oui mais pas portable est-ce bien cela?)

Et pour finir j'essaye de free le tout
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 void FreeIndex(struct index *A) { struct index *temp, *tempToFree; /*free(A);*/ if(A){ temp = A; do{ tempToFree = temp; temp = temp->suivant; free(tempToFree); }while(temp != NULL); }else printf("vide"); }
Le programme plante lors du free pas trop d'idée pq je suis à l'aise avec les pointeurs mais c'est la première fois que j'utilise des pointeurs de pointeurs.
Comment peut-on vérifier que le free c'est vraiment produit?

De plus lors de l'affichage de mon index chaîné (actuellement 1 seul éléments pour les test) cela n'affiche pas le résultat voulu.

j'aimerais un petit Feedback également sur les fonctions réalisés.

J'ai également une question concernant les caractères spéciaux pour les pseudo comment puis-je les géré n'est pas trop casse gueule en C? et y à-t-il moyen de gérer ça de manière portable?

11/06/2018, 01h03
foetus

Citation:

Envoyé par Sparky95

Le programme plante lors du free pas trop d'idée pq

documentation free (<- lien cplusplus.com anglais)

Citation:

Notice that this function does not change the value of ptr itself, hence it still points to the same (now invalid) location.

Si tu veux une traduction nécessite pas :langue2:
11/06/2018, 01h33
Sparky95

oui je suis au courent qu'il ne changes pas le pointeur il désalloue juste la mémoire pointé par celui si
c'est pour ça que je me demandais si l'on pouvaient récupérer la taille de la mémoire allouée et comment vérifier que cette mémoire ai bien été désalloué avant de "libérer le pointeur".
j'étais sur tutoriel point qui donnes +/- les même info que cplusplus.com.
J'ai peur de me balader parfois sur cplusplus.com de risque d'avoir du code C++ justement ^^
11/06/2018, 01h40
foetus
Citation:

Envoyé par Sparky95

oui je suis au courent qu'il ne changes pas le pointeur il désalloue juste la mémoire pointé par celui si

Donc si tu es au courant et comme tu cherches un plantage, explique moi cette partie de ton code :whistle:
Code:

1 2 3 4 5 6 7 8 free(A); if(A) { temp = A; // ... temp = temp->suivant;

arf easy le free du dessus est un test de derniere minute avant de poster XD
initialement il ne doit pas y être dans ma question:p

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
void FreeIndex(struct index *A)
{
	struct index *temp, *tempToFree;
	free(A);/*ligne que je n'avais pas mis dans mon code original. Je l'ai rajouté pendant les débug ^^*/
/*	
	if(A){
		temp = *A;
		do{
			tempToFree = temp;
			temp = temp->suivant;
			free(tempToFree);
		}while(temp != NULL);
	}else
		printf("vide");
*/	
}

11/06/2018, 08h45
Matt_Houston
Citation:

Envoyé par Sparky95

Code:

printf("%d\n", *pIndex->user.server);

Pourquoi le compilateur crie-t-il? comment résoudre?

Difficile de le savoir puisque tu ne nous transmets pas le message d'erreur en question, prends cette habitude ! Je penche tout de même pour le fait que *pIndex->user.server n'est pas de type int comme tu l'espérais, à cause d'une méconnaissance de l'ordre d'évaluation des opérateurs.

Citation:

Envoyé par Sparky95

Comment puis-je vérifier que le malloc c'est bien passé?

C'est précisé dans sa documentation et probablement dans la section du cours qui traite de l'allocation dynamique également.

Citation:

Envoyé par Sparky95

Puis-je de manière portable récupérer ça taille ? (D'apres mes recherches oui mais pas portable est-ce bien cela?) [...] Comment peut-on vérifier que le free c'est vraiment produit?

Non, (oui) et non, à ces trois questions. Le fait est que le langage part du principe que tu n'as jamais besoin de demander la taille, puisqu'à l'origine c'est toi qui fournit cette information !

Ta fonction d'allocation / instanciation est inutilement compliquée. À quoi peut bien servir cette variable intermédiaire tmpIndex ?

Et puis ça (j'ai simplifié) :
Code:

1 2 3 4 5 6 7 8 struct index tmpIndex, *start; start = malloc(sizeof tmpIndex); if (start) start = &tmpIndex; return start;
Peux-tu nous détailler ce que fait ce morceau de code, ligne par ligne ? Et pourquoi ce n'est pas une bonne chose ?

Citation:

Envoyé par Sparky95

J'ai également une question concernant les caractères spéciaux pour les pseudo comment puis-je les géré n'est pas trop casse gueule en C? et y à-t-il moyen de gérer ça de manière portable?

Autre sujet, autre thread.

Citation:

Envoyé par Matt_Houston

Difficile de le savoir puisque tu ne nous transmets pas le message d'erreur en question, prends cette habitude ! Je penche tout de même pour le fait que *pIndex->user.server n'est pas de type int comme tu l'espérais, à cause d'une méconnaissance de l'ordre d'évaluation des opérateurs.

fonctions.c:89:26: error: request for member 'user' in something not a structure or union
printf("%d\n", *pIndex->user.server);
Citation:
Envoyé par Matt_Houston
Ta fonction d'allocation / instanciation est inutilement compliquée. À quoi peut bien servir cette variable intermédiaire tmpIndex ?

Et puis ça (j'ai simplifié) :
Code:

1 2 3 4 5 6 7 8 struct index tmpIndex, *start; start = malloc(sizeof tmpIndex); if (start) start = &tmpIndex; return start;
Peux-tu nous détailler ce que fait ce morceau de code, ligne par ligne ? Et pourquoi ce n'est pas une bonne chose ?

Autre sujet, autre thread.
Le but étant par la suite de récupérer les données dans un fichier
mais vu que j'avais des bugg de malloc j'ai mis cette partie encore en cours de modif en commentaire
j'ai donc créé le tmpIndex qui serrait une variable local pour récupérer les donnée dans le fichier
Code:

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 struct index* LoadUsers(FILE *fichier) { struct index tmpIndex, *start = NULL; struct user *user; //fread(&tmpIndex.user, sizeof(tmpIndex.user), 1, fichier); Lecture du fichier tmpIndex.user.server = 166;//mis pour tester dans le main si cela s'est bien enregistré => dans le code final je l'aurais supprimé tmpIndex.suivant = NULL;//j'initialise le pointeur next a NULL start = (struct index*)malloc(sizeof(tmpIndex)); if(start){ //if(start) vérifie si il y a eu malloc start = &tmpIndex; if(DEBUG) printf("Malloc créé: adresse: %d", start); // le if(debug) un print de debug } else printf("erreur lors de la création de mise en mémoire\n"); //else,... dans le cas ou le malloc c'est mal passé /* le while,... serra la boucle pour lire les éléments suivants dans le fichier que je devrai encore placer dans le if (start) par la suite while(!feof(fichier)){ for(cpt ) }; */ return start; }

11/06/2018, 21h52
Sparky95
Je viens de trouver pour le pointeur de pointeur de structure.
Il fallait que je mets des parenthèses.

Code:

(*pIndex)->user.server

Parcontre pourquoi est-ce que dans mon main j'obtiens une adress
http://prntscr.com/jts9nu
Code:

1 2 MajIndex14 = UpdateIndexFichier(FICHIER14, &p14); printf("%d\n", p14->user.server);
12/06/2018, 10h43
Matt_Houston
Prenons les choses dans l'ordre, ne construis pas la maison tant que la recette du mortier n'est pas au point.

Tu n'as pas répondu aux questions posées plus haut :
Citation:
Envoyé par Matt_Houston

Code:

1 2 3 4 5 6 7 8 struct index tmpIndex, *start; start = malloc(sizeof tmpIndex); if (start) start = &tmpIndex; return start;

Peux-tu nous détailler ce que fait ce morceau de code, ligne par ligne ? Et pourquoi ce n'est pas une bonne chose ?

sisi je l'ai fais
Code:

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 struct index* LoadUsers(FILE *fichier) { struct index tmpIndex, *start = NULL; struct user *user; //fread(&tmpIndex.user, sizeof(tmpIndex.user), 1, fichier); Lecture du fichier tmpIndex.user.server = 166;//mis pour tester dans le main si cela s'est bien enregistré => dans le code final je l'aurais supprimé tmpIndex.suivant = NULL;//j'initialise le pointeur next a NULL start = (struct index*)malloc(sizeof(tmpIndex)); if(start){ //if(start) vérifie si il y a eu malloc start = &tmpIndex; if(DEBUG) printf("Malloc créé: adresse: %d", start); // le if(debug) un print de debug } else printf("erreur lors de la création de mise en mémoire\n"); //else,... dans le cas ou le malloc c'est mal passé /* le while,... serra la boucle pour lire les éléments suivants dans le fichier que je devrai encore placer dans le if (start) par la suite while(!feof(fichier)){ for(cpt ) }; */ return start; }
donc ligne 1 "prototype je pense que c s'appel"
3 et 4 déclaration structures
6 mon futur fread en commentaire (serra l'initialisation de tmpindex)
8 un test a supprimer dans le futur => modification de tmpIndex.user.server
9 initialistation de tmpIndex.suivant

11 initialisation pointeur start vers une zone mémoire mallocé
13 vérifie si il y a eu malloc (vérifier si le pointeur pointe bien vers la zone mallocé)
14 mise dans le malloc la strucuture index // pas sure

26 retour de l'adresse du malloc

12/06/2018, 12h19
Bousk
Code:

1 2 3 4 start = (struct index*)malloc(sizeof(tmpIndex)); if(start){ //if(start) vérifie si il y a eu malloc start = &tmpIndex;
Tu écris litérallement : alloue de la mémoire, et si tu as réussi pointe vers cette donnée interne.
Entraînant au passage une fuite mémoire.

Donc soit ta fonction retourne NULL si l'allocation échoue, soit elle retourne un pointeur invalide à la sortie de la fonction. En gros dès que tu l'appelles, au mieux tu ne retournes rien, soit t'as une fuite et retournes un pointeur invalide et un crash (ou autre comportement indéterminé) plus loin.

Si tu veux vraiment mise dans le malloc la strucuture index, tu veux affecter des données à la zone pointée, et non au pointeur, et donc *start = tmpIndex;, ou memcpy(start, &tmpIndex, sizeof(tmpIndex));.

cv je comprends mieux bête faut :p
Merci

Donc si je fais ceci je ne risque pas d'avoir de problemes mémoire?

Code:

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
int main(void){
	struct index *p14;
	bool MajIndex14;
 
	MajIndex14 = UpdateIndexFichier(FICHIER14, &p14);
 
	printf("%d\n", p14->user.server);
 
	FreeIndex(p14);
    return 0;
}
 
bool UpdateIndexFichier(char* Adress, struct index **pIndex)
{
	FILE *fichier;
	bool status = false;
 
	if((status = TestFile(Adress))){
		if((fichier = fopen(Adress, "rb"))){
			*pIndex = LoadUsers(fichier);
			fclose(fichier);	
		}else
			printf("ERREUR lors de l'ouverture du fichier %s\n", Adress);
	}else
		printf("Maj Index impossible: Ouverture de fichier impossible\n");
	return status;
}
 
struct index* LoadUsers(FILE *fichier)
{
	struct index tmpIndex, *start = NULL;
 
	tmpIndex.user.server = 166;
	tmpIndex.suivant = NULL;
 
	start = (struct index*)malloc(sizeof(tmpIndex));
 
	if(start)
		*start = tmpIndex;
	else
		printf("erreur lors de la création de mise en mémoire\n");
 
	return start;
}
 
void FreeIndex(struct index *A)
{
	struct index *temp, *tempToFree;
 
	if(A){
		temp = A;
		do{
			tempToFree = temp;
			temp = temp->suivant;
			free(tempToFree);
		}while(temp != NULL);
	}else
		printf("vide");
 
}

auriez vous faient comme cela? ou comment auriez vous faient votre/vos fonctions?

12/06/2018, 13h41
Bousk

Personnellement je serais plutôt partisan de faire l'allocation en premier, puis remplir les champs si elle réussit.
Ou mieux, de passer en paramètre la structure à remplir via pointeur, et retourner true/false si ça peut échouer (fichier non trouvé, ...).
12/06/2018, 13h45
Sve@r

Bonjour

Citation:

Envoyé par Sparky95

auriez vous faient comme cela? ou comment auriez vous faient votre/vos fonctions?

Moi, plutôt que de passer par des pointeurs de pointeurs, j'utilise toujours une structure supplémentaire pour "tenir" ma liste. Cette structure contient donc l'adresse du premier élément et c'est cette structure que je passe à mes fonctions. Les fonctions reçoivent cette structure et peuvent donc modifier ce premier élément si besoin.
Comme je dis toujours, on peut tenir une chemise par le col mais c'est mieux si on la pose sur un cintre.

Un exemple complet ici.

Citation:

Envoyé par Bousk

Personnellement je serais plutôt partisan de faire l'allocation en premier

Comme ceci?

Code:

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
41
42
43
44
45
46
 
struct index* LoadUsers(FILE *fichier)
{
	struct index tmpIndex, *start = NULL, *new = NULL;
	bool erreur = false;
 
	start = (struct index*)malloc(sizeof(tmpIndex));
	if(start){
		if(DEBUG) printf("Malloc créé: adresse: %d\n", start);
 
		fread(&start->user, sizeof(tmpIndex.user), 1, fichier);
		start->suivant = NULL;	
 
		while(!feof(fichier) && !erreur){
 
			new = (struct index*)malloc(sizeof(tmpIndex));
			if(new){
				fread(&new->user, sizeof(tmpIndex.user), 1, fichier);
				new->suivant = NULL;	
				InsertUser(start, new);
			}else{
				printf("erreur lors de mise en mémoire\n");
				erreur = true;
			}
		}
	}else
		printf("erreur lors de la création de mise en mémoire\n");
	return start;
}
/*
*/
void InsertUser(struct index* A, struct index* B)
{
	struct index *temp;
	bool quitter = 0;
 
	temp = A;
	while(strcmp(temp->user.pseudo, B->user.pseudo) < 0 && quitter != 1){
		if(temp->suivant == NULL)
			quitter = 1;
		else
			temp = temp->suivant;
	}
	B->suivant = temp->suivant;
	temp->suivant = B;
}

12/06/2018, 16h46
Sparky95

Citation:

Envoyé par Sve@r

Moi, plutôt que de passer par des pointeurs de pointeurs, j'utilise toujours une structure supplémentaire pour "tenir" ma liste.

Je vais lire ca tantot car c'est vrais que je ne suis pas trop fan des pointeurs de pointeurs :mrgreen::mouarf:
12/06/2018, 17h52
Sparky95

Citation:

Envoyé par Bousk

Entraînant au passage une fuite mémoire.

Dans le cas ou l'utilisateur arrête le programme brutalement style un "Ctrl+C".
Que ce passe-t-il avec la mémoire alloué?
Est-elle libéré? je suppose que non comment gérer des cas comme celui la?
12/06/2018, 18h16
Matt_Houston

S'il ne s'agit que de libérer la mémoire demandée alors c'est fait automatiquement par l'OS à la terminaison du processus, inutile de mettre en œuvre une gestion explicite de ce genre de cas.

Si d'autres traitements doivent être réalisés alors il faut faire un peu de programmation système, ou utiliser une bibliothèque qui gère cela (libuv, par exemple). Sous UNIX, on installe une callback - un signal handler - qui va être invoquée à la réception d'un signal d'un type donné ; SIGTERM pour ctrl+C, par exemple.
12/06/2018, 18h29
Sparky95

Citation:

Envoyé par Matt_Houston

S'il ne s'agit que de libérer la mémoire demandée alors c'est fait automatiquement par l'OS à la terminaison du processus

Pourquoi doit-on avant la fin du programme free la liste chaînée alors?

et non pas seulement lorsqu'on supprime un élément
je ne comprends pas trop cela :s
12/06/2018, 19h41
Sve@r

Ben déjà rien ne t'interdit d'appeler "n" fois la fonction de suppression d'un élément pour les supprimer tous et libérer ainsi toute ta liste.
Sinon c'est surtout une question à la base de "conscience professionnelle". Il est de bon ton pour les développeurs professionnels de libérer les ressources allouées avant de quitter et non se laisser aller à faire confiance à l'OS. Comme il est de bon ton d'éteindre en quittant les toilettes.

Et toutefois ça peut aussi être une question de portabilité. Les OS modernes effectivement libèrent la mémoire allouée à la fin du programme mais il n'en est pas ainsi des OS anciens (Windows XP par exemple ne le faisait pas). Et tu n'es pas certain que ton code ne sera pas implanté sur un OS un peu archaique et un peu exotique...
12/06/2018, 20h07
Bousk

Et puis surtout, un programme n'est pas toujours aussi simpliste. Quand il tourne pendant un moment, parfois des heures ou jours, de nombreuses allocations peuvent se faire pour du traitement, si tu ne libères pas au fur et à mesure que tu n'en a plus besoin, un moment donné l'os n'aura plus de mémoire disponible à te prêter.
12/06/2018, 21h37
Sparky95

ça va merci beaucoup à vous tous pour l'aide et le support apporté :king:
je vous recontacterai si j'ai d'autre questions sur les alloc
12/06/2018, 22h06
sambia39

Bonsoir,
Je vais rebondir sur ce que @Sve@r a avancé. Pour faire simple, il n’est nul par écrits dans la norme qu’à la fin du programme la désallocation se fait automatiquement ou que le système d’exploitation se charge de désallouer la mémoire de façon automatique et ceux que l’on soit sous un système d’exploitation ancien ou nouveau. Si c'était le cas, cela serait précisé dans la norme en remplaçant « The lifetime of an allocated object extends from the allocation until the deallocation » par « The life of an allocated object extends from the allocation to the de-allocation, termination or end of the program. »

Donc, si vous allouez de la mémoire, vous devez la désallouer avant que votre programme se termine. Si vous ne faites pas cela, votre programme ne respecte donc pas la norme et n’est pas portable.
à bientôt
12/06/2018, 23h43
Sparky95

Oui mais du coup dois-je désallouer dans le cas ou l'utilisateur nous fait une petite interruption sauvage?
Ou non pas besoin?
Je parles ici dans l'étique d'un programme propre :)
13/06/2018, 00h25
Sparky95
autre petite question rapide pour éviter d'ouvrir une nouvelle discussion
Citation:
Envoyé par souviron34

c'est pourtant simple et on l'a répété 250000 fois sur ce forum..

FEOF NE S'UTILISE PAS COMME CA
ON NE TESTE PAS LA FIN DE LECTURE COMME CA....
Je lis ici qu'il "engueule" une personne car elle a fait une boucle lecture fichier avec en condition de sortie feof(fichier).
Pourquoi n'est-ce pas bon?
surtout qu'ici cela est fait en exemple dans le cours sur la lecture et écriture dans les fichiers
13/06/2018, 08h31
Bktero

souviron34 engueulait tout le temps tout le monde (je l'aimais bien lui....) et pour le coup il avait raison. Regarde cette entrée de la FAQ qui explique bien pourquoi : https://c.developpez.com/faq/?page=E...-fonction-feof Ce cours que tu montres n'est pas tout à fait juste, ou plutôt il fait un raccourci. En fait, cette méthode fonctionne tant que ta lecture n'échoue pas et que tu atteints sans encombre la fin du fichier. Et tu viens par la même occasion (mais tu l'avais déjà peut-être compris avec cette histoire de libération de la mémoire) que le C n'est pas un langage facile, avec beaucoup de petites choses que plusieurs personnes n'ont pas interprété de la même manière.... ou pas avec la même rigueur.

Citation:

Envoyé par Bktero

https://c.developpez.com/faq/?page=E...-fonction-feof

Je n'ai pas trop compris cette partie de code
Code:

1 2 3 4 5 6 7 8 9 10 if (feof(fp)) { printf("Fin de fichier atteinte !\n"); printf("La taille du fichier est : %ld octets.\n", taille); } else { if (ferror(fp)) printf("Arret du programme en raison d'une erreur de lecture !\n"); }
This function returns a non-zero value when End-of-File indicator associated with the stream is set, else zero is returned.
Car sur ce site il est mis si je ne me trompes pas: cette fonction retourne une val !0 lorsqu'on arrive à la fin sinon un 0.

Du coup while (!feof(Fich)) ferrait un tour de boucle de trop vu qu'il arrive a la fin du fichier mais la valeur est !0 et donc il continue jusqu’à arriver à l'erreur?
est-ce bien ça?

du coup je devrais plutot faire ma fonction comme ceci?
basé sur https://www.geeksforgeeks.org/eof-and-feof-in-c/
Code:

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 struct index* LoadUsers(FILE *fichier) { struct index tmpIndex, *start = NULL, *new = NULL; bool erreur = false; fread(&tmpIndex.user, sizeof(tmpInde.user, 1, fichier); if(tmpIndex.user != EOF){ start = (struct index*)malloc(sizeof(tmpIndex)); if(start){ if(DEBUG) printf("Malloc créé: adresse: %d\n", start); //fread(&start->user, sizeof(tmpIndex.user), 1, fichier); //fscanf(fichier, "%d/%d %s %s", &start->user.server, &start->user.id, start->user.pseudo, start->user.pseudo_ingame); *start = tmpIndex; start->suivant = NULL; while(!erreur && fread(&tmpIndex.user, sizeof(tmpInde.user, 1, fichier) != EOF){ new = (struct index*)malloc(sizeof(tmpIndex)); if(DEBUG) printf("Malloc créé: adresse: %d\n", new); if(new){ //fread(&new->user, sizeof(tmpIndex.user), 1, fichier); //fscanf(fichier, "%d/%d %s %s", &new->user.server, &new->user.id, new->user.pseudo, new->user.pseudo_ingame); *new = tmpIndex; new->suivant = NULL; InsertUser(start, new); }else{ printf("erreur lors de mise en mémoire\n"); erreur = true; } } }else printf("erreur lors de la création de mise en mémoire\n"); }else printf("fichier vide\n"); return start; }
J'imagine que je ne peux pas faire ça car EOF retournes un character or mon index.user attends un int est bien ça?
comment pourrais-je le faire autrement?
j'airais comme idée lire un char pour retourner un cran en arriere mais bon c'est pas super niveau optimisation :s

Si je peux me le permettre, je pense qu'il faut peut-être mettre à jour la FAQ sauf erreur de ma part (dans ce cas mes excuses par avance).
Il est écrit dans la FAQ que "la fonction feof() ne sert pas à détecter la fin d'un fichier, mais, lorsqu'une lecture a échoué, à savoir si cet échec est dû à la rencontre de la fin de fichier.
". Hors que, feof() ne sert pas non plus a ça, il renvoie une valeur non-nulle si et seulement si l'indicateur de fin de fichier pour le flux "X" est activé. En d'autres termes feof(), renvoie une valeur qui est non-nulle si la fin du fichier associée au flux "X"a été atteinte lors d'une lecture précédente. Pour détecter les erreurs, il faut utiliser ferror qui renvoie une valeur non-nulle si et seulement si l'indicateur d'erreur pour le flux de x est défini/activé, indiquant qu'une erreur s'est produite lors d'une opération précédente sur le flux en plus clair si l'opération de lecture/ecriture a été faite ferror va tester si l'opération effectuée sur le flot en question à générée une erreur ou non; en cas d'erreur, ferror retourne l'indicateur d'erreur/la valeur non-nulle qui correspond à l'erreur a ceci prés que l'indicateur d'erreur reste actifs même-ci une l'on effectue une autre opération réussie; pour levée cette erreur, il faut donc procéder a la mano au désengagement de l'indicateur d'erreur en utilisant la fonction clearerr.

Ceci dit, le code proposé dans la FAQ comporte une erreur non-détectable dû non pas à un mauvais emploi de la fonction feof()/ferror(), mais plutôt a un mauvais contrôle de flux puisque dans les faits, si l'on a une erreur dans la boucle de traitement exemple une instruction parasite (void)fputc('A',fp); (voir autres) l'erreur ne sera pas détectée, et ce, tout simplement parce que ferror() est en dehors de la boucle. Normalement si elle est placée dans la boucle vous deviez avoir comme du style erreurs (8) bad descriptor.
Code:

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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 #include <stdio.h> #include <stdlib.h> int main(void) { FILE * fp = fopen("source.c", "rb"); if (fp == NULL) fprintf(stderr, "La fonction fopen a echoue.\n"); else { int c; long taille = 0; while ((c = fgetc(fp)) != EOF) { /* Utilisation du caractère lu. */ /* Dans notre cas, on n'en a rien à faire. */ /* On incrémente tout simplement notre compteur. */ if (ferror(fp)) printf("Arret du programme en raison d'une erreur de lecture !\n"); taille++; /* * /!\ INJECTION /!\ * detection d'erreurs impossible */ fputc('A', fp ); } if (feof(fp)) { printf("Fin de fichier atteinte !\n"); printf("La taille du fichier est : %ld octets.\n", taille); } else { if (ferror(fp)) printf("Arret du programme en raison d'une erreur de lecture !\n"); /* * Autre erreur, il faut un désengagement de l'indicateur d'erreur * en utilisant la fonction X cas contraire l'erreur est toujours * actifs & faire une sorti contrôler. */ clearerr(fp); return EXIT_FAILURE; } } return 0; }
Autres point plus important en passant qu'il faut tout de même mentionner. Il faut faire attention à l'emploi d'EOF sur les fichiers sous un système d'exploitation de type GNU/Linux. Tout simplement parce que sous GNU/Linux, les fichiers sont en réalité considérés comme binaire.

Très souvent, les diverses raisons de la difficulté de l’emplois des fonctions feof()/ferror() sont dues à comment doit-on placer les fonctions pour contrôler, sortir/détecter les erreurs de flux dans la boucle, c'est-à-dire la façon/le moyen le plus évident d'utiliser feof()/ferror() pour contrôler une boucle/detecter des erreurs voir les deux. S'il faut réécrire dans un premier temps l'ensemble de ce que j'avance cela s'apparenterais au code source-ci dessous, mais attention, c'est un exemple il peut donc y avoir des erreurs surtout qu'il y a une autre façon d'écrire les instructions.
Code:

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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main( void ) { int ret = 0; FILE *p = NULL; /* * Ouverture du fichier */ if( NULL == ( p= fopen("source.c", "r") ) ){ (void)fprintf(stderr, "(%d)Erreur\t: ouverture de fichier\n\t:%s\n", errno, strerror(errno) ); return EXIT_FAILURE; } /* * traiment */ errno = 0; for(;;){ ret = fgetc(p); if( EOF == ret ){ if( feof(p) ){ (void)fprintf(stderr, "\nfin de flux\n" ); /* * Utilisation de abort(), dont, le traitement dépendra * du système d'exploitation hôte. */ if( EOF != fclose(p) ){ p = NULL; return EXIT_SUCCESS; } (void)fprintf(stderr, "Erreur critique close file impossible\n"); /* * Cependant abort déclenche un arrêt brutale et volontaire * du programme avec un signal SIGABRT dû a l'échec de la * fonction fclose cela est probablement dû a une erreur liée * a des erreurs sous-jacentes du système d'exploitation * qui ne peut être contournée. */ abort(); // } } /* * detection d'erreurs */ if( ferror(p) ){ (void)fprintf(stderr, "(%d)Erreur\t:%s\n", errno, strerror(errno) ); clearerr(p); return EXIT_FAILURE; } (void)fprintf(stderr, "%c", ret ); /* * Dé-comenter si vous souhaitez * générer une erreur l'instruction ci-dessous */ //(void)fputc('A', p ); } // Instruction jamais atteinte return EXIT_FAILURE; }
@Sparky95: Pour répondre à votre question, si vous prenez en compte le SIGINT (CTRL+C) alors vous devez vous assurerez de désallouer la mémoire allouée cas contraire, le système hôte se chargera de prendre les mesure nécessaire. Personnellement, je vous le déconseille. Laisser le gestionnaire par défaut faire sont travail.
Il faut juste comprendre ceci ; un programme qui se termine n'a pas de fuites mémoire. Seul un programme en cours d'exécution peut avoir des fuites mémoires. Une fois que le programme sort, toute la mémoire est libérée ou réattribue, mais il faut respecter tout de même la norme et les règles de portabilité ; un malloc = un free = respect de la norme = programme portable.
à bientôt.

13/06/2018, 14h42
Sparky95

@sambia39 ça va merci beaucoup par-contre je dois vous avouer que vous m'avez perdu des le début des explications :aie:
Je n'ai compris que la fin des explications à partir du moment ou vous m'expliquez les fuites mémoires
13/06/2018, 14h56
Sve@r
Citation:

Envoyé par sambia39

Pour faire simple, il n’est nul par écrits dans la norme qu’à la fin du programme la désallocation se fait automatiquement ou que le système d’exploitation se charge de désallouer la mémoire de façon automatique

Cela ne pourra jamais être écrit. La norme du C ne peut pas impliquer l'OS...

Citation:

Envoyé par Sparky95

Oui mais du coup dois-je désallouer dans le cas ou l'utilisateur nous fait une petite interruption sauvage?
Ou non pas besoin?
Je parles ici dans l'étique d'un programme propre :)

Ca dépend. Si tu programmes le coeur d'une centrale nucléaire, ou bien le contrôle du pilote automatique d'un Airbus; alors oui vaudrait mieux que ton programme soit ultra blindé et ultra redondant.
Si maintenant tu programmes la gestion du carnet d'adresse de la secrétaire ben tu n'es pas obligé d'aller aussi loin...
Tout est question de compromis entre la criticité de ton programme et le temps passé à le blinder. De mon avis personnel, je pense que la bonne approche (en général) est de considérer que le programme ira jusqu'à la fin et de programmer donc la libération classique et ne pas te préoccuper de l'interruption sauvage ctrl-c (où tu as quand-même de grandes chances que ce soit alors géré par l'OS).

Citation:

Envoyé par Sparky95

Du coup while (!feof(Fich)) ferrait un tour de boucle de trop vu qu'il arrive a la fin du fichier mais la valeur est !0 et donc il continue jusqu’à arriver à l'erreur?
est-ce bien ça?

Exact. Quand tu lis le dernier caractère, l'OS ne sait pas encore que c'est le dernier. C'est quand tu tentes de lire après ce dernier que là, la fonction de lecture échoue et que le flag "End Of File" est levé.

Accessoirement, si tu réfléchis bien, nous aussi nous fonctionnons ainsi. Quand on lit un texte, et qu'on arrive au dernier mot de la dernière ligne, on ne peut pas à priori savoir qu'on est sur ce dernier mot. C'est en analysant la phrase lue, et aidé de la ponctuation, qu'on détecte alors que c'était la fin. C'est certes un mécanisme extrèmement rapide et presque instantané que fait ton cerveau; mais c'est quand-même une action qui peut s'apparenter à "on essaye de lire après pour alors comprendre qu'il n'y a plus rien à lire".

Donc pour l'ordi, c'est pareil. Il s'ensuit que ce type de traitement...
Code:

1 2 3 4 5 char c; while (!feof(fp)) { c=lecture(fp) traitement c }
... ne fonctionne pas car tu lis le dernier caractère, tu traites le dernier caractère, le flag End Of File n'est pas levé, feof() renvoie 0, tu tentes alors de lire après le dernier caractère, la fonction échoue mais tu traites quand-même la variable "c" (qui, n'ayant pas été modifiée, contient toujours le caractère de la lecture précédente). Bref tu traites deux fois le dernier caractère.

Pour résoudre, tu corriges en testant la lecture ce qui donne
Code:

1 2 3 4 5 char c; while (!feof(fp)) { if ((c=lecture(fp)) == valeur_speciale_indiquant_que_la_lecture_ne_s_est_pas_faite) break; traitement c }
Ok, là ça fonctionne. Mais là, ton oeuil d'aigle examine ce code et constate alors que ça peut se simplifier en
Code:

1 2 3 4 char c; while ((c=lecture(fp)) != valeur_speciale_indiquant_que_la_lecture_ne_s_est_pas_faite) traitement c }
Et du coup, feof() n'a plus de raison d'être (ce qui est normal puisque son rôle n'est pas de détecter la fin de fichier). Certes rien ne t'interdit de l'utiliser (comme dans mon second exemple) tout comme rien ne t'interdit d'utiliser une perceuse pour planter un clou, mais dans les deux cas tu te compliques la vie en n'utilisant pas les outils adaptés au but à atteindre.

Citation:

Envoyé par Sparky95

J'imagine que je ne peux pas faire ça car EOF retournes un character or mon index.user attends un int est bien ça?
comment pourrais-je le faire autrement?

Euh... Je ne suis pas certain de bien saisir la phrase "EOF retourne un caractère". EOF c'est une valeur spéciale (qui doit probablement valoir -1) et qui est renvoyée quand la fonction de lecture échoue. EOF ne peut donc rien retourner.
Tel que je lis ton code (tant que lecture ne retourne pas EOF) ça me semble bon. Si le fread() se fait alors il charge tmpIndex.user avec l'int lu ; et s'il ne peut pas se faire, alors d'une part il ne remplira pas tmpIndex.user (qui restera alors inchangé de la lecture précédente) et d'autre part il renverra la valeur EOF que tu détecteras et sortiras de la boucle...
13/06/2018, 15h21
Sparky95

cv merci beaucoup pour ces explications le feof et EOF n'étaient que des notions vues pour moi :p

Citation:

Envoyé par Sve@r

Euh... Je ne suis pas certain de bien saisir la phrase "EOF retourne un caractère". EOF c'est une valeur spéciale (qui doit probablement valoir -1) et qui est renvoyée quand la fonction de lecture échoue. EOF ne peut donc rien retourner.
Tel que je lis ton code (tant que lecture ne retourne pas EOF) ça me semble bon. Si le fread() se fait alors il charge tmpIndex.user avec l'int lu ; et s'il ne peut pas se faire, alors d'une part il ne remplira pas tmpIndex.user (qui restera alors inchangé de la lecture précédente) et d'autre part il renverra la valeur EOF que tu détecteras et sortiras de la boucle...

J'avais mal compris le EOF

et je me référais à ceci ceci

Code:

while (ch != EOF)
13/06/2018, 15h56
Bktero

@sambia39 : ergoter (en plus face à un débutant) avec des trucs délirants, ça devient une habitude à laquelle il faudrait faire attention 8O

https://media.giphy.com/media/1hAY6P...jvuo/giphy.gif

Ah et dans le cas présent je me demande même si ce n'est pas faux en plus... En effet, je suis sceptique de voir que ton deuxième code ne semble pas détecter plus d'erreur que le premier. Et j'ai bien décommenté la ligne...

Citation:

Envoyé par Bktero

Ah et dans le cas présent je me demande même si ce n'est pas faux en plus... En effet, je suis sceptique de voir que ton deuxième code ne semble pas détecter plus d'erreur que le premier. Et j'ai bien décommenté la ligne...

Je suis assez d'accord (tout à l'heure j'avais pas trop décortiqué ce qu'il avait écrit)

@sambia: je pense que dans ce code
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 while ((c = fgetc(fp)) != EOF) { /* Utilisation du caractère lu. */ /* Dans notre cas, on n'en a rien à faire. */ /* On incrémente tout simplement notre compteur. */ if (ferror(fp)) printf("Arret du programme en raison d'une erreur de lecture !\n"); taille++; /* * /!\ INJECTION /!\ * detection d'erreurs impossible */ fputc('A', fp ); }
Je ne vois pas trop en quoi détecter l'erreur dans la boucle sera mieux que de la détecter en dehors.
Déjà (je peux me tromper car j'ai pas examiné en détail la doc de ferror()) mais il me semble que cette fonction ne détecte que les erreurs de lecture graves (arrêt du disque, éjection de la clef USB, etc) et non les erreurs du type "je tente d'écrire dans un flux ouvert en lecture" car ce dernier cas est alors remonté par le retour de fputc() (qui vaut alors -1) et errno qui se positionne sur la cause de l'erreur. Et donc (encore une fois je dis ça sans avoir testé mais juste réfléchi à la logique du truc) ferror() ne détecte rien.

Donc pour moi, le bon code (c'est à dire fonctionnant sans faire d'opérations inutiles) est le suivant
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 while ((c = fgetc(fp)) != EOF) { /* Utilisation du caractère lu. */ /* Dans notre cas, on n'en a rien à faire. */ /* On incrémente tout simplement notre compteur. */ taille++; /* * /!\ INJECTION /!\ * detection d'erreurs sur la fonction d'écriture */ if (fputc('A', fp) < 0) fprintf(stderr, "Erreur d'écriture fp - %s\n", strerror(errno)); } if (feof(fp)) printf("Fichier traité\n"); elif (ferror(fp)) fprintf(stderr, "Fichier incomplètement traité - %s\n", strerror(errno));
Et encore, j'ai mis elif (ferror(fp)) n'étant pas certain qu'il n'y avait pas une 3° possibilité mais je suis quasiment sûr que le test de fin peut s'écrire plutôt
Code:

1 2 3 4 if (feof(fp)) printf("Fichier traité\n"); else fprintf(stderr, "Fichier incomplètement traité - %s\n", strerror(errno));
Ou inversement
Code:

1 2 3 4 if (ferror(fp)) fprintf(stderr, "Fichier incomplètement traité - %s\n", strerror(errno)); else printf("Fichier traité\n");
Citation:

Envoyé par sambia39

Autres point plus important en passant qu'il faut tout de même mentionner. Il faut faire attention à l'emploi d'EOF sur les fichiers sous un système d'exploitation de type GNU/Linux. Tout simplement parce que sous GNU/Linux, les fichiers sont en réalité considérés comme binaire.

Je ne vois pas trop le rapport entre "comme quoi est considéré le fichier" et "la valeur retournée par la fonction qui le lit quand elle ne peut plus le lire"...:weird:

Par ailleurs j'ai l'impression à te lire que "considéré comme binaire" c'est être l'exception. Alors que justement les fichiers binaires sont la norme. Ce sont des fichiers dans lesquels "une information" se traduit par "le nombre exact d'octets nécessaires au codage de l'information" (ex un float se traduira par 4 octets parce qu'un float se code sur 4 octets) ; ce qui est tout à fait sensé et logique. Ce sont au contraire les fichiers textes Windows qui sont les débiles. Chez-eux, un caractère informatif peut se traduire par un ou deux caractères physiques (ex le "end of line", qui est bien "un" caractère informatif, qui se traduit par deux caractères physiques '\r' suivi de '\n'). Ce sont bien eux donc qui sont les tarés de la bande. Ce sont eux qui mettent la zone chaque fois qu'on veut programmer un algo générique de traitement de fichier. J'irai même dire que c'est dommage qu'il faille spécifier "b" quand on appelle fopen() parce que ça laisse sous-entendre qu'être binaire c'est être l'exception qui doit se gérer différement. Moi, j'aurais tout considéré par défaut comme binaire et j'aurais programmé la fonction fopen() pour qu'on lui passe "t" quand on veut ouvrir du texte.
Les fichiers Linux sont des fichiers normaux, basiques, standards ; fichiers dont tous les autres OS devraient prendre exemples. :king:

13/06/2018, 20h36
sambia39
Citation:

Envoyé par Sve@r

Je ne vois pas trop en quoi détecter l'erreur dans la boucle sera mieux que de la détecter en dehors.
Déjà (je peux me tromper car j'ai pas examiné en détail la doc de ferror()) mais il me semble que cette fonction ne détecte que les erreurs de lecture graves (arrêt du disque, éjection de la clef USB, etc) et non les erreurs du type "je tente d'écrire dans un flux ouvert en lecture" car ce dernier cas est alors remonté par le retour de fputc() (qui vaut alors -1) et errno qui se positionne sur la cause de l'erreur. Et donc (encore une fois je dis ça sans avoir testé mais juste réfléchi à la logique du truc) ferror() ne détecte rien.

Pour expliquer ce que j'ai écrit, je pars de là:
(7.21.10.2) : The feof function tests the end-of-file indicator for the stream pointed to by stream. The feof function returns nonzero if and only if the end-of-file indicator is set for stream.
The ferror function tests the error indicator for the stream pointed to by stream. The ferror function returns nonzero if and only if the error indicator is set for stream.

Donc, une erreur de fin de fichier et une erreur de lecture peuvent être distinguées et détectées par l'utilisation des fonctions feof et ferror.
dans le cas du premier code issue a la base du FAQ que j'ai ajouter des instruction.
1. Le fichier est ouvert en lecture.
2. L’emploi ou l’appel de la fonction fputc va générer une erreur parce que le fichier est en lecture et non en écriture.
3. ferror va détecter l’erreur sur le flux du fichier parce que l’appel de la fonction précédente a généré une erreur sur le flux.
4. Si ont emplois pas la fonction clearerr l’indicateur d’erreur reste actifs et donc le seconde teste de ferror est toujours vrais puisqu’il y a erreur.
à quel moment ferror détecte l'erreur s'il se trouve hors de la boucle et ce sachant également que l'on a un feof juste avants. Quand est t'il également si feof lis un fichier vide ?

@Sve@r dans votre code, vous testez bien la tentative d’écrire d’un caractère ( il y'a un garde fou); Si celle-ci échoue elle affiche une erreur, mais si le programme continu son exécution "tout de même" on obtiendrais comme resltats, le message suivants fprintf(stderr, "Erreur d'écriture fp - %s\n", strerror(errno)); en boucle puis viens le teste de fin de fichier qui affichera a son tour "Fichier traité" quand est t'il alors pour le message d’erreur de ferror ?. C’est là ou dans mon dernier message, j’explique que la difficulté ici n’est pas l’emploi des fonction mais ou les placer pour détecter une éventuelle erreur de traitement sur le flux de fichier avant que l’on atteigne la fin du fichier et non après. Tester donc en mettant (2) devant le message d'erreur de ferror et dite moi ce que vous en pensé.

Citation:

Envoyé par Sve@r

Je ne vois pas trop le rapport entre "comme quoi est considéré le fichier" et "la valeur retournée par la fonction qui le lit quand elle ne peut plus le lire"...:weird:

Pour répondre à votre question. En ma connaissance sauf erreur de ma part, sur les systèmes tel qu'Unix ou GNU/Linux il n'y a pas vraiment voir/aucun moyen de déterminer le type de fichier sans l'ouvrir ou faire la différence entre un fichier texte simple et un fichier binaire. Le seul moyen est la lecture des octets magique/signature (exemple [4F 67 67 53] pour ogg ou [25 50 44 46] pdf) du fichier ou la lecture d’un certain nombre d’octets et donc par défaut le système d’exploitation considère le/les fichier comme étants binaire. Plus en détails, parce que sur les systèmes d’exploitation Unix ou GNU/Linux leurs systèmes de fichiers ne stocke aucune information permettant de conaître leur contenue et donc faire la distinction, entre un fichier text d’un binaire. La seule prérogative en ma connaissance est l’utilisation des répertoires pour faire une distinction (si je peux dire ainsi) exemple le repertoire /bin/ par exemple, car elle caractérise le format du fichier en question. Et sans vouloir faire des vagues ou en fâché plus d’un. GNU/Linux tout comme Unix utilise rarement les extensions de fichiers.
Pour plus de détails, je vous invite a lire Filesystem Hierarchy Standard , le diff ou
Binary Files and Forcing Text Comparisons

Citation:

Envoyé par Bktero

@sambia39 : ergoter (en plus face à un débutant) avec des trucs délirants, ça devient une habitude à laquelle il faudrait faire attention 8O

Ah et dans le cas présent je me demande même si ce n'est pas faux en plus... En effet, je suis sceptique de voir que ton deuxième code ne semble pas détecter plus d'erreur que le premier. Et j'ai bien décommenté la ligne...

@Bktero: Tout d’abord le premier code, c’est le code qui vient directement du FAQ dans lequel j’ai ajouté le nom du fichier « source.c » à lire, la fonction ferror() dans la boucle de traitement et la fonction clearerr; Je mets l’accent sur le fait que l’on ne détecte pas les erreurs de flux. Quant au seconde, c’est bien mon exemple.
Deuxième point en quoi j’ai avancé des choses délirante ? Dans ce que j’ai écris à @Sparky95.
13/06/2018, 22h34
Bktero
Encore une fois, tu ne te mets pas au niveau du PO. Il est clair que c'est quelqu'un qui n'est pas très à l'aise avec le C et rentrer dans un tel niveau de pinaillage sur des détails ne peut pas l'aider. Dommage que tu ne t'en rendes pas compte...

Puisque j'y suis, parlons des extraits de code. Histoire que j'explique au moins pourquoi je pense que c'est faux.

1) Déjà, il y l'idée de dire que le code la FAQ est faux. Schématiquement ce code donne ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 while ((c = fgetc(fp)) != EOF) { // traitement de c } if (feof(fp)) { // Fin de fichier atteinte } else if (ferror(fp)) { // Erreur rencontrée }
En ouvrant le man de fgetc(), on apprend que fgetc renvoie EOF en cas d'erreur ou de fin de fichier :

Citation:

fgetc() reads the next character from stream and returns it as an unsigned char cast to an int, or EOF on end of file or error.

Il faudra vraiment m'expliquer ce qui est faux dans cette boucle... Si la boucle s'arrêter, c'est qu'on rencontré un de ces deux cas. Le premier se teste avec feof(), le second avec ferror(). On peut se poser la question d'un else et de ce qu'on pourrait y mettre dedans mais ce cas semble hautement improbable.

2) Ton premier code montre une boucle sur la même condition et le premier truc fait dans la boucle est de regarder ferror(). Mais comment ferror() pourrait bien remonter une erreur puisque fgetc() n'a pas renvoyé EOF (sinon, on ne serait pas dans la boucle, non ? :? ) et qu'on ne fait aucune opération sur le fichier après ? Là aussi, je ne comprends pas...

3) Attaquons l'idée d'injecter une soi-disant erreur... Non mais allô ?! On marche sur la tête !!! :evilred: C'est un code qui lit un fichier pour en déterminer la taille et toi tu te dis "hé regardez si j'écris dedans ça fait n'importe quoi". Non mais tu expliques comment faire de l'électricité et tu dis attention si vous branchez votre système d'arrosage en même temps à l'intérieur de la maison ça va faire des étincelles.

4) Je passe ton deuxième code avec des trucs qui font mal aux yeux et tue la lisibilité.

- Ca commence avec la déclaration de la variable FILE* p qu'on initialise à NULL pour ensuite l'affecter à l'intérieur d'un if : tu t'es dit que c'était un exemple pour un débutant un truc aussi moche ?
- Les cast en (void) des retours de fprintf() pour éviter des vieux warnings utilisés uniquement dans les projets paranoïaques.
- Les fautes de français dans les commentaires ("traiment" ligne 25)
- La boucle while(fgetc) qui devient un for(;;;) avec en prime une variable à la C89 en début de main()
- La mise à NULL de p inutile car suivi d'un return (ligne 40)
- L'absence de else parce qu'on a fait un return sauvage si on a réussit à fermer le fichier (ligne 43)
- Les fprintf() sur 3 lignes de 25 caractères (ligne 62) ou sur 2 lignes pour ne pas dépasser les 40 colonnes (on loin des 80 !!!) (ligne 69). Un stagiaire me montre un code comme ça, je lui demande gentiment d'aller retravailler un peu la mise en forme...
- Du code mort (enfin, documenté comme mort, j'ai pas pu le vérifier...) (ligne 81) 8O

5) Enfin, le plus gros quand même. J'ai testé tout à l'heure sous Windows 10 avec mingw64 et ça n'a détecté aucune erreur. Le fputc() a juste fait avant la position dans le fichier et donc le programme m'annonce une taille moins importante que la réalité.....mais ne détecte aucune erreur.

1 pièce(s) jointe(s)

Citation:

Envoyé par sambia39

Donc, une erreur de fin de fichier et une erreur de lecture peuvent être distinguées et détectées par l'utilisation des fonctions feof et ferror.

Exact. Je viens de tester
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #include <stdio.h> int main() { FILE *fp; int c; fp=fopen("/etc/passwd", "r"); while ((c=fgetc(fp)) != EOF) fputc(c, stdout); fputc(c, fp); if (feof(fp)) printf("feof\n"); if (ferror(fp)) printf("ferror\n"); fclose(fp); }
Effectivement le fputc(c, fp) lève un flag que ferror() détecte. Bon point pour toi je le reconnais car je ne savais pas qu'il allait jusqu'à détecter un truc aussi con que "oups j'ai écrit dans un flux dédié à la lecture".

Citation:

Envoyé par sambia39

à quel moment ferror détecte l'erreur s'il se trouve hors de la boucle et ce sachant également que l'on a un feof juste avants.

Ben feof() indique si le flag EOF a été levé ; et ferror() indique si le flag "file error" a été levé. Les deux flags ne sont pas exclusifs l'un de l'autre (ce que montre d'ailleurs mon exemple ci dessus)

Citation:

Envoyé par sambia39

Quand est t'il également si feof lis un fichier vide ?

Ben (avec mon exemple) ça marche aussi => la lecture renvoie EOF donc la boucle ne se fait pas mais le flag EOF est bien levé

Citation:

Envoyé par sambia39

@Sve@r dans votre code, vous testez bien la tentative d’écrire d’un caractère ( il y'a un garde fou); Si celle-ci échoue elle affiche une erreur, mais si le programme continu son exécution "tout de même" on obtiendrais comme resltats, le message suivants fprintf(stderr, "Erreur d'écriture fp - %s\n", strerror(errno)); en boucle puis viens le teste de fin de fichier qui affichera a son tour "Fichier traité" quand est t'il alors pour le message d’erreur de ferror ?

C'est juste une question de tests. Suffit de changer le test final en ceci
Code:

1 2 3 4 5 6 7 8 if (ferror(fp)) { // Erreur rencontrée } elif (feof(fp)) { // Fin de fichier atteinte }
Ou toute autre construction algorithmique permettant, selon le choix du programmeur, de privilégier le flag EOF, le flag error ou les deux ensembles (encore une fois comme mon exemple en haut de ce post).

Citation:

Envoyé par sambia39

C’est là ou dans mon dernier message, j’explique que la difficulté ici n’est pas l’emploi des fonction mais ou les placer pour détecter une éventuelle erreur de traitement sur le flux de fichier avant que l’on atteigne la fin du fichier et non après. Tester donc en mettant (2) devant le message d'erreur de ferror et dite moi ce que vous en pensé.

Ben voilà. Je viens de répondre.

Citation:

Envoyé par sambia39

Pour répondre à votre question. En ma connaissance sauf erreur de ma part, sur les systèmes tel qu'Unix ou GNU/Linux il n'y a pas vraiment voir/aucun moyen de déterminer le type de fichier sans l'ouvrir ou faire la différence entre un fichier texte simple et un fichier binaire.

Exact. Tout simplement parce qu'il n'y en a aucune. Sur Linux on a des fichiers qui contiennent du son, d'autres de la vidéo, d'autres qui contiennent des images, et d'autres qui contiennent des caractères ascii. Pour ces derniers il se trouve que les éditeurs les affichent bien proprement parce que ces fichiers indiquent, en plus du code ascii lisible, un caractère particulier spécifiant "ici on passe sur une autre ligne" que ces mêmes éditeurs donc détectent et traitent. Mais il en va de même avec une vidéo lue par vlc. La vidéo contient de l'image au format image (du pixel et de la position) que vlc sait récupérer et afficher à l'écran. Et (pour une vidéo ou un fichier ne contenant que de l'ascii) la distinction se fait par le programme chargé de le traiter ; pas par l'OS.

Citation:

Envoyé par sambia39

Le seul moyen est la lecture des octets magique/signature (exemple [4F 67 67 53] pour ogg ou [25 50 44 46] pdf) du fichier ou la lecture d’un certain nombre d’octets

C'est vrai qu'il y a les octets magiques. Mais ces octets ne sont pas à destination de l'OS mais des développeurs qui souhaitent pouvoir affiner plus spécifiquement et de façon automatique tel ou tel fichier (lui c'est de l'image, lui du son, lui de la vidéo). Mais ces distinctions ne sont déjà plus du ressort de l'OS ; seulement des humains qui utilisent ces fichiers.

Citation:

Envoyé par sambia39

et donc par défaut le système d’exploitation considère le/les fichier comme étants binaire.

Non. Il ne les considère pas comme binaires mais comme simples fichiers tout court. Mon premier code (en début de ce post) peut s'appliquer aussi bien à "/etc/passwd" qu'à "/boot/vmlinuz".

Mieux, on change le code en ceci
Code:

1 2 3 4 5 6 7 8 9 10 11 #include <stdio.h> int main(int argc, char *argv[]) { FILE *fp; int c; fp=fopen(argv[1], "r"); while ((c=fgetc(fp)) != EOF) fputc(c, stdout); fclose(fp); }
On compile ensuite ce code dans un exécutable "toto"; on tape ensuite "./toto xxx >yyy" et on aura "yyy" totalement identique au fichier "xxx" demandé ; quel que soit ce fichier et sa nature. Bref ce code est un ersatz (très minimaliste) de la commande "cp". Et nulle part dans ce code on se proccupe de la nature du fichier lu.

Citation:

Envoyé par sambia39

exemple le repertoire /bin/ par exemple, car elle caractérise le format du fichier en question.

Le répertoire "/bin" est le répertoire dédié aux "binaires" (d'où le nom bin=>binaire). Mais dans ce cas précis, le terme "binaire" ne veut pas dire "fichier binaire comme de l'image ou du son" mais "fichiers exécutables". Et en effet, le dossier "/bin" contient les commandes Unix/Linux (ex cp, ls, vi, more, rm, etc etc etc). Là encore, du point de vue OS pur, ce ne sont que des fichiers. Mais (petite particularité) ces fichiers possèdent un "magic number" spécifique qui fait que le noyau Linux sait les reconnaitre comme pouvant produire un processus => nous (humains) les appelons alors "exécutables". Alors c'est vrai que dans ce cas précis, Linux fait une petite différence. Mais il ne la fait que quand l'humain lui demande "d'exécuter" un programme. Bref il ne fait donc cette différence que quand un humain lui demande de la faire.
Et ce n'est pas pour que l'OS les reconnaisse qu'on les regroupe, mais pour que les programmeurs (humains) sachent où les trouver. Le répertoire "/bin" ne caractérise pas le format du fichier. C'est le contraire. C'est parce que on ne place dans ce dossier que des exécutables que le dossier /bin ne contient que des exécutables.

Citation:

Envoyé par sambia39

Et sans vouloir faire des vagues ou en fâché plus d’un. GNU/Linux tout comme Unix utilise rarement les extensions de fichiers.

Aucun OS n'utilise les extensions. ce sont là encore des conventions humaines. Unix ne sait pas que "toto.avi" c'est un film. Mais si je demande file toto.avi alors l'exécutable "file" (programmé par un humain) ira chercher les magic number de "toto.avi" et s'il le reconnait, alors il pourra indiquer "toto.avi est un film". Mais on est déjà sorti de l'OS. Et c'est un système équivalent sous Windows (là, il y a une correspondance entre "extension" et "nature" ; et cette correspondance est stockée dans la base de registre).

Citation:

Envoyé par sambia39

Pour plus de détails, je vous invite a lire Filesystem Hierarchy Standard

Ce document (je ne le connaissais pas mais je viens de le parcourir) indique l'arborescence type d'un Unix. Il dit que (par exemple) /bin est dévolu aux exécutables, que dans /etc on trouve la configuration, que dans /tmp on trouvera les fichiers de travail, etc etc. Ca ne parle absolument pas d'une quelconque distinction entre "fichiers binaires" et "fichiers texte". Et là aussi le fait que "/etc" ne contienne que des fichiers "human readable" tandis que "/bin" ne contient que des fichiers exécutables est encore une volonté des développeurs. Et là encore l'OS ne fait aucune différence.

Citation:

Envoyé par sambia39

le diff ou Binary Files and Forcing Text Comparisons

Ce sont des documents dédiés aux développeurs du programme "diff" (qui eux ont besoin parfois de différencier telle ou telle nature de fichier) pour les aider à optimiser ce programme (destiné à afficher les différences entre deux fichiers) selon la nature des fichiers à comparer. Mais là encore on n'est plus dans l'OS, on a basculé dans l'humain.

En fait, Unix ne connait que 6 types de fichiers
le fichier de type "répertoire". C'est un fichier structuré sur 2 colonnes. L'une contient le nom, l'autre le numéro d'inode. C'est la traduction informatique de ce qu'est un répertoire (un fichier contenant des fichiers). Et grâce à l'association nom/inum, le système Unix sait, quand on demande à accéder à tel fichier, si déjà le fichier est présent (grâce au nom) et ensuite, s'il l'est, où aller le chercher sur disque (grâce à son inode). Et là, si ce fichier est lui-même un dossier, alors rebelote.
le fichier de type "lien symbolique". C'est un fichier qui contient le chemin d'un autre fichier. Là l'OS sait, quand on demande à l'ouvrir, aller chercher le lié correspondant. Et si ce lié est lui-même un lien symbolique alors rebelote.
le fichier spécial de type "bloc" ou "caractère". Ce sont les fichiers associés aux IO (on trouvera par exemple /dev/null (la poubelle), /dev/sda (le premier disque sata), /dev/ptx/N (correspondant à une fenêtre de commande dans ton environnement de bureau (moi j'utilise xfce)) et bien d'autres encore. Même si ce sont deux types distincts on a l'habitude de les mettre ensemble parce qu'ils ont le même but (gérer les IO). Certaines IO se font bloc par bloc (les disques) tandis que d'autres se font caractère par caractère (les écrans) d'où la distinction. Et comme ils sont vraiment différents des autres (ce ne sont pas des fichiers au sens "ils contiennent des datas" mais plutôt des points d'entrée vers le noyau), on les regroupe dans le dossier "/dev" (comme "devices"). Mais là encore /dev n'est pas un dossier pour "typer" les devices, c'est juste un dossier où tous les devices sont regroupés ensembles de par la volonté des développeurs.
le fichier de type "pipe". C'est un fichier permettant de faire communiquer de façon réglementée deux processus
le fichier de type "socket". Analogue au pipe sauf que la communication n'est pas réglementée
et enfin le fichier dit "ordinaire" ; qui va regrouper tous les fichiers de données. Là, pour l'OS, ces fichiers ne contiennent que des octets en vrac. Et dans tout ce fatras, là on verra apparaitre des distinctions mais cette fois humaines (parce que hors OS) pour indiquer "lui c'est une image", "lui c'est une vidéo", "lui ce sont mes comptes bancaires" ou "lui c'est ma liste de commissions pour demain".

A cette liste bien établie certains rajoutent un 7° type qui est le lien physique (ln toto titi). Personnellement je ne suis pas tout à fait d'accord car créer un lien consiste juste à rajouter un second nom dans un dossier, nom pointant vers le même numéro d'inode que le fichier originel. Or, ce fichier originel est lui-même typé selon les 6 types ci-dessus. Et le type du fichier étant stocké dans son inode (qui reste unique), il s'ensuit que le nouveau fichier est alors du même type que le fichier originel (créer un lien sur un fichier pipe donnera un second fichier pipe). Donc bref pour moi un lien physique n'est pas un 7° type mais plutôt une duplication d'un des 6 types déjà existants).

Ci-joint un tuto sur les différents types de fichiers Unix.

@Bktero:
je n’ai pas écrit que le code était faux, mais qu’il comporte une erreur et je ne parle pas non plus de la boucle en elle-même, je parle du fait qu’il faut effectuer le test d’indicateur d’erreur dans la boucle.

Dans mon premier code oui, je vérifie l’indicateur d’erreur dans la boucle pour savoir s’il n’y a pas eu d’erreurs entre temps sur le flux, car je ne peux absolument pas garantir si ma lecture/mon écriture dans le fichier a réussi où réussiront à la prochaine boucle (tout peut arriver.) et justement ferror() teste s’il n’y a pas eu entre-temps un indicateur d’erreur d'activer après l’exécution de l’instruction précédente si c’est le cas, je ne poursuis pas le déroulement du programme, je sors immédiatement avec un code erreurs. J’ai volontairement injecté un caractère pour simuler une hypothétique erreur quelconque survenue ; certes, ici, c’est une tentative d’écriture, mais le principe d'une erreur est là. Et même-ci à la place, c'était un autre type d’erreur ; avec aucune vérification d'erreur de flux/flot, l'erreur ne sera détectée.
Ici, le sujet n'est pas de déterminer la taille du fichier, il y a déjà un exemple dans la FAQ. Ici, c'est l'exemple de l'empois de feof & ferror() donc, je parle de comment on pourrait utiliser ferror() pour détecter les erreurs de flux.
On y vient :
4.1-> J’initialise ma variable pointeur a NULL car c’est a mon habitude peut importe ce que les gens diront là dessus; pas besoin/ ou non de l’initialiser voir critiqué. Et n’y a rien de moche à vouloir écrase la valeur que contient ma variable pointeur. Et en quoi, c’est moche ?.

4.2-> Tu te plantes, si je n’utilise pas le retour d'une fonction; je mets un void cas contraire elle sera utilisée.
4.3-> Faute de Français là au moins ont est d’accord et je te l’accorde.
4.5->Une boucle 'pour’ oui et une variable pointeur mise a NULL OK des instructions sur plusieurs lignes oui et alors ??
Si tu as testé sous Windows 10; OK, mais a tu au moins compris que sur le flux (p) il y'a eu une erreur?
(Juste comme ça ; fputc(‘A’, p); génère bien une erreur). Je vais encore mettre un code dégueulasse sans boucles avec mon fgetc() et peut-être que tu comprendras.
Code:

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 int ret = 0; errno = 0; FILE *p = NULL; if( NULL == ( p = fopen("source.c", "r") ) ) return EXIT_FAILURE; ret = fgetc(p); (void)fprintf(stderr, "%c\n", ret ); fputc('A', p ); // indicateur d'erreur activé ret = fgetc(p); (void)fprintf(stderr, "%c\n", ret ); // (void)fprintf(stderr,"Errno = %d\n\t:%s\n", errno, strerror(errno) ); /* * Erreur de le flux */ if( (ret = ferror(p)) ){ (void)fprintf(stderr, "Erreur %d - %d\n", errno, ret ); clearerr(p); return EXIT_FAILURE; } (void)fprintf(stderr, "Pas d'erreur\n"); (void)fclose(p); p = NULL;
@Sve@r: Arf, j'ai loupé votre message ceci dit, je prends volontiers votre manuel et les remarque sur les fichiers Unix ça pourrais m'être très bénéfique. Merci pour le partage.
à bientôt.

S'il n'est pas faux alors il est correct. Mais s'il est correct, comment peut-il contenir une erreur ? Logique implacable...

J'ai essayé ce nouveau code que tu proposes et sous Windows 10 avec mingw64, et ça m'affiche ça :
1
3
Errno = 0
	:No error
Pas d'erreur
En revanche sous Xubuntu ça fonctionne :
Code:

1 2 3 4 5 h e Errno = 9 :Bad file descriptor Erreur 9 - 1
Au passage, je suis bien d'accord que c'est une erreur d'écrire sur un flux ouvert en lecture seule.

J'ai écrit ce code :
Code:

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 #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main(void) { int c = EOF; FILE* p = fopen("data.txt", "r"); if(p == NULL) { fprintf(stderr, "Ouverture impossible %d %s\n", errno, strerror(errno)); return EXIT_FAILURE; } while(EOF != (c = fgetc(p))) { /* Afficher le caractere */ putchar(c); /* Creer une erreur */ fputc(c, p); /* Regarder l'indicateur d'erreur du flux */ if(ferror(p) != 0) { fprintf(stderr, "\nErreur detectee %d %s\n", errno, strerror(errno)); return EXIT_FAILURE; } } fclose(p); return EXIT_SUCCESS; }
Sous Windows 10 comme sous Xubuntu, il me sort ça :
1357
Erreur detectee 9 Bad file descriptor
Pourquoi mon code fonctionne et pas le tien, mystère pour le moment... Ce que je veux dire c'est qu'on est en train de discuter de détails, visiblement en plus non portable Windows / Linux. Et honnêtement.... ce n'est pas utile.

Au passage, tu verras que mon code ne caste pas en (void) les retours non utilisés, initialise directement p avec le retour fopen() pour avoir un if() bien plus lisible derrière, et il compile très bien en C89 avec gcc -std=c89 -Wall -Wextra -pedantic main.c. Si tu ne vois pas la différence de lisibilité, alors je pense qu'on va arrêter là notre débat, on ne se mettra jamais d'accord ;)

Citation:

Envoyé par Bktero

S'il n'est pas faux alors il est correct. Mais s'il est correct, comment peut-il contenir une erreur ? Logique implacable...
......
J'ai essayé ce nouveau code que tu proposes et sous Windows 10 avec mingw64, et ça m'affiche ça :
Au passage, je suis bien d'accord que c'est une erreur d'écrire sur un flux ouvert en lecture seule.
.......
Pourquoi mon code fonctionne et pas le tien, mystère pour le moment... Ce que je veux dire c'est qu'on est en train de discuter de détails, visiblement en plus non portable Windows / Linux. Et honnêtement.... ce n'est pas utile.

Au passage, tu verras que mon code ne caste pas en (void) les retours non utilisés, initialise directement p avec le retour fopen() pour avoir un if() bien plus lisible derrière, et il compile très bien en C89 avec gcc -std=c89 -Wall -Wextra -pedantic main.c. Si tu ne vois pas la différence de lisibilité, alors je pense qu'on va arrêter là notre débat, on ne se mettra jamais d'accord ;)

Oui, on obtient bien une erreur. Et cette erreur que tu obtiens est dûe au fait que tu as effectué un contrôle sur le flux/flot juste après une lecture/écriture pour t’assurer de détecter d’éventuelles erreurs survenues lors de l’opération précédente (lecture/écriture). Et tu as donc placé ce contrôle au plus prés des opérations effectuées, t’assurant la détection d’erreurs le plus tôt possible. Et depuis le début, j’essaie de te le faire comprendre que je ne parle pas de code faux ou correct, mais d’erreur dûe à la difficulté (et le plus souvent) de trouver ou placer la fonction de contrôle de flux/flots de façon à détecter une éventuelle erreur de traitement.

Mis à part les deux points sur lesquels on est d’accord à savoir les fautes de français et ferro(), on peut parler du code et de logique implacable ; vu que tu t’es efforcé dès le départ à donner tes explications sur la qualité de mes différents codes sources (rassure-toi, tu auras d’autres occasions d’en débattre) ; mais en attendant, essayons d’élucider le mystère du "Pourquoi mon code fonctionne et pas le tien, mystère pour le moment..." sachant que mes codes ont été faits non pas pour être corrects, mais illustrer le plus possible l'erreur/ le comportement du programme à la détection ou non-détection d’une erreur sur le flux. Donc, je vise le comportement du programme et non la qualité du code et cela s’appelle effectuer une erreur de spécification volentaire.

Ce qui m’étonne, c’est ta question sur le mystère de savoir pourquoi ça ne marche pas sur Windows 10. Toi qui es très féru de qualité de code et de logique implacable, tu n’as su déterminer à aucun moment qu’il n'y a pas de mystère ; tu aurais dû remarquer certaines choses notamment entre/à partir de la ligne 15 à… .Voici, Quelques orientations, ferror, effectue un test d’erreur de lecture ou d’écriture sur le fichier associé au flux/flot et en cas d’erreur de lecture ou d’écriture sur le Flux/flot, l’indicateur d’erreur pour le flux sera activée et restera active jusqu’à ce que le flux soit fermé ou jusqu’à ce que clearerr() soit appelé. Mais si le flux est NULL, ferro invoque le gestionnaire de paramètres invalide (du moins sous un environnement Windows et probablement Unix). Si l'exécution peut se poursuivre, cette fonction met dans la variable errno, EINVAL et renvoie zéro donc déjà avec ça, tu pourras peut-être comprendre probablement le comportement que pourrait avoir le programme dans un environnement Windows et élucider un mystère de code pourri. Au passage, cela démontre également que tu ne prends pas nécessairement en compte l’environnement dans lequel le programme va évoluer et ne me dis surtout pas que c’est une question de portabilité vu que tu as un exemple type que cela n’est pas lié à la portabilité du code d’autant plus. Je me cite en passant sur ce que j’ai pu écrire concernant mes codes sources.

Citation:

Envoyé par sambia39

...dans la FAQ comporte une erreur non-détectable dû non pas à un mauvais emploi de la fonction feof()/ferror(), mais plutôt a un mauvais contrôle de flux puisque dans les faits, si l'on a une erreur dans la boucle de traitement exemple une instruction parasite (void)fputc('A',fp); (voir autres) l'erreur ne sera pas détectée, et ce, tout simplement parce que ferror() est en dehors de la boucle. Normalement si elle est placée dans la boucle vous deviez avoir comme du style erreurs (8) bad descriptor.
......
Très souvent, les diverses raisons de la difficulté de l’emplois des fonctions feof()/ferror() sont dues à comment doit-on placer les fonctions pour contrôler, sortir/détecter les erreurs de flux dans la boucle, c'est-à-dire la façon/le moyen le plus évident d'utiliser feof()/ferror() pour contrôler une boucle/detecter des erreurs voir les deux. S'il faut réécrire dans un premier temps l'ensemble de ce que j'avance cela s'apparenterais au code source-ci dessous, mais attention, c'est un exemple il peut donc y avoir des erreurs surtout qu'il y a une autre façon d'écrire les instructions.
......
Je vais encore mettre un code dégueulasse sans boucles avec mon fgetc() et peut-être que tu comprendras.

Parlons maintenant de ton code source. J’ai tout de même testé à mon tour ton programme sur Windows 10 avec un compilateur bien de chez Microsoft sans option, sous une machine virtuelle et j’obtiens bien comme résultat le message d’erreur, chose qui est bien. En revanche, ce qui m’intéresse est ta logique implacable. Commençons par le message d’erreur et quelques éléments qui sont absents dans ton code, mais disons que ce n’est pas bien grave.
Dans ton exemple, on obtient bien une erreur "mauvais descripteur de fichier", cela est effectivement dû à une opération non permise sur un descripteur de fichier ouvert en lecture seule. Donc il faut s’assurer de signifier que l’opération est dûe à une opération non permise, car on a manipulé un descripteur de fichier en lecture seule. Et quand on quitte/gère le comportement de son programme lors d’une erreur avant de quitter, on ne laisse pas le programme hôte gérer l’échec d’un programme. Il faut prendre les mesures appropriées en amont avant de pouvoir quitter proprement et signifier au système hôte que le programme a quitté en raison d’une erreur (sans rentrer dans un débat de descripteur de fichier sous un environnement Windows/Unix). Donc un clearerr ne fera pas de mal.

Pour encore ne pas être d’accord avec toi, voici un programme dégueulasse dans lequel j’emploie volontairement une boucle "pour" avec une variable existante uniquement le temps de la boucle et beaucoup moins lisible. J’aimerais savoir ce que tu en penses :(.
Code:

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 #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main( void ){ FILE *p = NULL; if( NULL == (p = fopen("source.c", "r")) ){ (void)fprintf(stderr, "(%d)Erreur\t:%s\n", errno, strerror(errno) ); return EXIT_FAILURE; } for( int r = 0; !feof(p); r = ferror(p) ){ if( r ){ (void)fprintf(stderr, "\nErreur dûe à :%s\nCause :%s\n", strerror(r), strerror(errno) ); clearerr(p); return EXIT_FAILURE; } (void)fputc( fgetc(p), stderr ); (void)fputc('c', p ); } if( EOF == fclose(p) ){ (void)fprintf(stderr, "Erreur: %d %s\n", errno, strerror(errno)); return EXIT_FAILURE; } p = NULL; return EXIT_FAILURE; }
À bientôt.

17/06/2018, 15h18
Sve@r

Citation:

Envoyé par sambia39

Pour encore ne pas être d’accord avec toi, voici un programme dégueulasse dans lequel j’emploie volontairement une boucle "pour" avec une variable existante uniquement le temps de la boucle et beaucoup moins lisible. J’aimerais savoir ce que tu en penses :(.

Euh... déjà moi je n'en pense pas tellement du bien. Mais pas tellement pour le "r" dans la boucle (ça c'est autorisé depuis C99 et je trouve ça pas plus mal) mais pour tout le reste.
Tout d'abord, tu utilises feof() pour tester la fin de lecture (lecture dans le cas où tout se passe bien je veux dire) alors qu'il est dit depuis le début que cette fonction ne sert pas à ça. Total, si tu supprimes la ligne (void)fputc('c', p ) qui provoque une erreur de flux, alors le code s'exécute et lit tout le fichier mais il affiche à la fin un caractère de plus que ce que contient réellement le fichier lu.
Ensuite ben en cas d'erreur tu quittes sans avoir fermé le fichier. De plus tu remets à zéro les flags du fichier alors que tu quittes la fonction. De même à la fin du code tu mets p à NULL alors que tu ne le traites plus (ne jamais remplir une variable sans la traiter ensuite). Et enfin tu écris le caractère lu sur le flux stderr (c'est un flux dédié aux messages d'erreur, pas aux messages normaux du code).

Et tous ces casts à la c.. !!! Tu penses vraiment être propre en écrivant ainsi ? Tu ne sais pas que le trop est l'ennemi du bien ?? Tu ne connais pas le cast implicite ??? Surtout que le cast a un but quand-même: celui de pouvoir faire traiter le truc casté dans un traitement qui le verra différemment de ce qu'il est. Ex int i; for (i=1; i < 10; i++) printf("%f\n", (i+1)/float(i)). Si là je ne caste pas le "i" en float, alors ma division ne se fera pas comme je le souhaite (et accessoirement j'ai mis du temps à trouver cet exemple qui n'est même pas à 100% démonstratif car on peut faire autrement => printf("%f\n", (i+1.0)/i) ce qui prouve que dans la 98% des cas, le cast peut s'éviter).
Ici quel est le but de tes casts ? Juste dire "je ne prendrai pas en compte le retour de printf()". Hé ben ne le prends pas en compte quoi. Tout simplement. C'est complètement idiot d'écrire "je ne ferai pas telle opération". Suffit de simplement ne pas la faire. C'est comme les gens qui disent "je voudrais dire..." ben ils n'ont qu'à le dire, c'est beaucoup plus simple !!!

Et (dernier détail) tes inversions d'égalité (écrire if( NULL == (p = fopen("source.c", "r")) au lieu de if ((p=fopen("source.c", "r")) == NULL)) et qui me font marquer un (mini) temps d'arrêt quand je lis ce type d'instruction pour la remettre dans le sens de lecture naturel. Alors ok ça protège de celui qui oublierait l'opérateur de comparaison du C (et qui écrirait if ((p=fopen("source.c", "r")) = NULL) mais bon, t'es-t-il déjà arrivé d'écrire "=" en pensant "==" ? Si ça t'es arrivé, combien de temps t'as mis pour touver l'erreur et la corriger ?

En C (et probablement dans d'autres langages), il y a l'écriture scolaire, rigoriste, et qui produit un truc qui pique les yeux ; et il y a ensuite l'écriture intuitive, naturelle, peut-être moins académique mais tellement plus en adéquation avec notre logique naturelle...

Voir 40 message(s) de cette discussion en une page