fgets problème utilisation code de la faq

Bonjour,

j'ai regardé la faq à la question : Comment lire une ligne de manière sécurisée ?

J'ai fait un code naïf des plus simple en reprenant le code de la question de la faq mais cela me renvoi rien.
Je suis sous mingw32-make et la version est c11.

Voici mon code :

Code:

---

1 2 3 4 5 6 7 8 9

char * Filename_RecoveryInputUser(void) { // fgets me renvoi rien on dirait qu'il bug car il ne m'affiche même pas la chaîne. char *pFilename = fgets(pFilename, PATH_MAX, stdin); printf("%s\n", pFilename); pFilename[strlen(pFilename)-1] = '\0'; return pFilename; }

---

De plus comme pFilename est une variable local normalement elle est détruite quand la fonction ce termine.
Donc faire retourner pFilename même si celui-ci n'est pas null on perd l'adresse retourné non ?

Citation:

---

Envoyé par hbx360

Donc faire retourner pFilename même si celui-ci n'est pas null on perd l'adresse retourné non ?

---

Il faut recopier la chaîne de caractères avec la fonction strcpy (<- lien cplusplus.com en anglais)

Donc soit

• Soit tu crées 1 chaîne de caractères en local avec malloc, tu fais la recopie, et tu la retournes. Donc c'est la fonction appelante, qui récupére l'adresse retournée avec 1 assignation, et qui a la responsabilité de libérer cette chaîne de caractères.
• Soit tu passes en paramètres 1 double pointeur char** (<- qui est en réalité l'adresse d'1 chaîne de caractères, &str), tu fais la recopie avec en déréférencent évidement.

Bonjour

Citation:

---

Envoyé par hbx360

char *pFilename = fgets(pFilename, PATH_MAX, stdin);

---

Ca c'est pas bon. fgets(s, n, flux) a pour action de récupèrer "n-1" caractères depuis "flux" et stocker ces caractères dans "s", "s" étant donc prévue pour pouvoir stocker ces "n-1" caractères (+1 pour le '\0'). Donc "s" doit être à minima un tableau de caractères soit dynamique (ie char s[1000]), soit alloué, soit provenant de l'appelant.
Accessoirement, ensuite fgets() retourne "s" ok, mais ce retour est donc un truc déjà existant au préalable. Elle aurait pu tout aussi bien renvoyer 1 ou n ou n'importe quoi différent de 0. Là tu déclares un pointeur, pointeur qui récupère le retour d'un truc qui le reçoit en paramètre tout en n'existant pas encore. Quelque part ça ne peut pas fonctionner. C'est presque comme si tu te prenais les pieds par en dessous en espérant t'envoler.

Pour simplifier: la partie droite du "=" est toujours évaluée avant la partie gauche. Donc tu n'as absolument pas le droit d'utiliser dans cette partie droite un élément qui n'existe pas encore.

Citation:

---

Envoyé par hbx360

Donc faire retourner pFilename même si celui-ci n'est pas null on perd l'adresse retourné non ?

---

Hé oui. C'est évidemment une conséquence directe du problème ci-dessus.

En admettant que ton code soit comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <stdio.h> #include <string.h>   #define PATH_MAX 1000   char * Filename_RecoveryInputUser(void) { // fgets me renvoi rien on dirait qu'il bug car il ne m'affiche même pas la chaîne. char *pFilename = fgets(pFilename, PATH_MAX, stdin); printf("%s\n", pFilename); pFilename[strlen(pFilename)-1] = '\0'; return pFilename; }

---

Tu devrais surtout avoir un warning de ton compilateur :

prog.c: In function 'Filename_RecoveryInputUser':
prog.c:10:20: warning: 'pFilename' is used uninitialized in this function [-Wuninitialized]
   9  |  char *pFilename = fgets(pFilename, PATH_MAX, stdin);
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Tu as bien mis les options qui vont bien à ton compilateur ? (pour gcc et clang : -Wall -Wextra)

Citation:

---

Envoyé par foetus

Il faut recopier la chaîne de caractères avec la fonction strcpy (<- lien cplusplus.com en anglais)

Donc soit

• Soit tu crées 1 chaîne de caractères en local avec malloc, tu fais la recopie, et tu la retournes. Donc c'est la fonction appelante, qui récupére l'adresse retournée avec 1 assignation, et qui a la responsabilité de libérer cette chaîne de caractères.
• Soit tu passes en paramètres 1 double pointeur char** (<- qui est en réalité l'adresse d'1 chaîne de caractères, &str), tu fais la recopie avec en déréférencent évidement.

---

Mais pourquoi copier avec strcpy ?

Si on te passe le buffer, fgets() écrit dedans et c'est bon. Si non, tu crées le buffer, fgets() écrit dedans, tu le renvoies et c'est bon.

Citation:

---

Envoyé par Bktero

Mais pourquoi copier avec strcpy ?

---

Parce que je n'ai pas compris la question "Donc faire ?" :whistle:

Et donc, j'ai répondu de façon générale :wow:
Ensuite la fonction fgets retourne son paramètre (1 truc de la libc qui permet de chaîner les appels), mais le paramètre doit être 1 vrai tableau : dans l'exemple ce n'est pas très clair :koi:
Parce que si tu crées 1 tableau fixe local char file_str[XXX];, tu ne peux pas le retourner. Il faut faire 1 recopie :mrgreen:

Le code que je vous ai posté c'est celui de la faq, il faudrait faire les modifications nécessaire je pense .

Voici le code de la faq :

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

char * read_stdin(char * buffer, size_t taille) { char * result = fgets(buffer, taille, stdin);   if (result != NULL) { char * lf = strchr(buffer, '\n'); /* On cherche le caractère '\n'. */   if (lf != NULL) /* S'il est présent, ... */ *lf = '\0'; /* ... on le supprime */ else { /*   * Le '\n' n'est pas présent. Ça signifie qu'il reste au moins un   * caractère dans stdin. On peut choisir de les ignorer et de vider   * stdin ou d'agrandir le buffer si c'est possible (realloc()) et de   * rappeler fgets() autant de fois que nécessaire...   *   * Si on ne fait rien, la prochaine lecture sur stdin se fera sans attente   * et récupèrera ce qui n'a pas été lu ...   */ } }   return result; }

---

@foetus : ok compris.

Citation:

---

Envoyé par Sve@r

Code:

---

char *pFilename = fgets(pFilename, PATH_MAX, stdin);

---

Ca c'est pas bon.

---

Bin c'est le code de la faq.

@Bktero : bin je les ai pas mis je vais le faire.

J'ai une autre question quand je veux vider le buffer en utilisant le code de la faq mais avec fgetc au lieu de getchar, j'ai le problème suivant c'est qu'il faut que je tape 2 fois entrée pour que le programme passe à la suite. Et si je dit à l'utilisateur de taper sur entrée pour continué et bien idem faut que je le fasse 2 fois. J'ai le même problème avec getchar.
Y aurait-il une possibilité pour ne pas à avoir à taper entrée 2 fois ?


Voici une vidéo qui montre ce problème :

https://www.youtube.com/watch?v=UajORkoUTNQ

Voici mon code ou l'on entre le nom du fichier :

Code:

---

1 2 3 4 5 6 7 8 9

char pFilename[PATH_MAX]; // Buffer pour récupérer la saisie utilisateur (stdin). char * Filename_RecoveryInputUser(void) { fgets(pFilename, PATH_MAX, stdin); pFilename[strlen(pFilename)-1] = '\0'; Keyboard_CleanStdin(); return pFilename; }

---

Le code pour vider le buffer :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void Keyboard_CleanStdin(void) { s32 c; do { // Note : si on met stdin la console attendra toujours que l'utilisateur tape entrée, que ce soit // fgetc ou fgets pour valider. c = fgetc(stdin); }while(c != '\n' && c !=EOF); }

---

Mon autre code (la 2e ligne ou l'on tape entrée pour continuer) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void Filename_WaitingTxt(void) { char pInput[2] = {}; int i = 0;   printf("Attente. Tapez entrée pour continuer.\n"); fgets(pInput, 2, stdin); Keyboard_CleanStdin();   while( pInput[i] != '\n') { printf("Tapez entrée pour continuer.\n"); fgets(pInput, 2, stdin); Keyboard_CleanStdin(); } }

---

Citation:

---

Envoyé par hbx360

Bin c'est le code de la faq.

---

Y'a un monde entre le code de la FAQ qui prend un buffer en paramètre et l'utilise, puis stocke le retour de fgets dans une autre variable et ton truc qui crée un char* pFilename juste avant son utilisation dans fgets, sans aucune forme d'initialisation, tout en récupérant son retour dans la même variable. :weird:

J'ai recopié le code de la faq.
C'est la seul solution que j'ai trouvé, de déclarer mon tableau en variable global et de le retourner car je met la fonction dans une autre

Voici le code :

Code:

---

1 2	FILE *pFile = Filename_OpenFile(Filename_RecoveryInputUser(), "r", NULL);.

---

ATTENTION : j'ai pas dis que je critiquais la faq je signal un problème je cherche à comprendre je ne suis pas dans une démarche violente ni agressive et je suis dans le forum débutant. Merci de ne pas être agressif !

Tu peux tourner ça dans tous les sens que tu veux, ton code et celui de la FAQ n'ont rien à voir. Et le code de la FAQ est correcte. Le tien, non.
Quant à utiliser fgets pour retourne un char*, il t'a été expliqué plus haut comment faire.
fgets prend un buffer. Un buffer c'est pas un pointeur random. C'est de la mémoire qui doit exister, allouée dans la heap via malloc ou sur la stack.
Utiliser une globale pour ça c'est loin d'une bonne idée ou façon de faire.

Ok.

Comme déjà dit, la faq est correcte.

Une solution simple à ton problème

Code:

---

1 2 3 4 5 6

char * Filename_RecoveryInputUser(void) { char *pFilename = fgets(malloc(PATH_MAX),PATH_MAX,stdin); // en espérant que malloc() se passe bien printf("%s\n", pFilename); pFilename[strlen(pFilename)-1] = '\0'; return pFilename; }

---

Ok pas de soucie, c'est moi qui me suis précipité ; j'ai fait une erreur j'aurai dû mieux relire.

@edgarjacobs : merci pour ton code.

Le fait de déclarer

Code:

---

char pFilename[PATH_MAX]

---

en variable global je sais que c'est le mal mais c'est quand même pratique. Sinon oui j'aurai pu l'envoyé en argument dans la fonction

Code:

---

Filename_RecoveryInputUser

---

.

Merci à tous pour votre aide après pour les "2 fois entrée" je sais pas s'il y a possibilité de régler ça.

Je reviens sur mon code, donc vous me confirmé que ce code est moisie.

Le main :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include "includes.h"   int main(int argc, char const **argv) { freopen("CON", "w", stdout); printf("Saisir le nom du fichier.\n"); FILE *pFile = Filename_OpenFile(Filename_RecoveryInputUser(), "r", NULL); .........   return 0; }

---

Dans filename.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

FILE *Filename_OpenFile(char *pFilename, char *pMode, char *pErrorMsg) { FILE *pFile = fopen(pFilename, pMode); // fopen n'admet pas les '\n'. if(pFile == NULL && pErrorMsg == NULL) { printf("Failed to open file.\n"); } else if(pFile == NULL) { printf("Failed to open file.\n"); printf(pErrorMsg); printf("\n"); } return pFile; }     char pFilename[PATH_MAX]; // Buffer pour récupérer la saisie utilisateur (stdin).   char * Filename_RecoveryInputUser(void) { fgets(pFilename, PATH_MAX, stdin); pFilename[strlen(pFilename)-1] = '\0'; Keyboard_CleanStdin(); return pFilename; }

---

Merci désolé si je reviens la dessus.

Citation:

---

Envoyé par hbx360

Bin c'est le code de la faq.

---

Bin les posts suivants ont bel et bien prouvé que non. Accessoirement tu remarqueras l'intéressante coïncidence entre ma remarque "Donc s doit être à minima un tableau de caractères soit dynamique (ie char s[1000]), soit alloué, soit provenant de l'appelant." où justement dans la faq, "s" est effectivement provenant de l'appelant (remarque ce n'est pas vraiment une coincidence car il n'y a pas d'autre solution possible)

Citation:

---

Envoyé par hbx360

Je reviens sur mon code, donc vous me confirmé que ce code est moisie.

---

Non, juste quelques maladresses mais pas moisi. Voir mes commentaires directement dans ton code

Citation:

---

Envoyé par hbx360

Code:

---

1 2 3 4 5 6 7 8 9 10

int main(int argc, char const **argv) { freopen("CON", "w", stdout); printf("Saisir le nom du fichier.\n"); FILE *pFile = Filename_OpenFile(Filename_RecoveryInputUser(), "r", NULL); // Donc on admettra que Filename_RecoveryInputUser() ne peut pas planter. Ok, admettons, c'est pas vraiment grave. ......... return 0; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

FILE *Filename_OpenFile(char *pFilename, char *pMode, char *pErrorMsg) { FILE *pFile = fopen(pFilename, pMode); // fopen n'admet pas les '\n'. if(pFile == NULL && pErrorMsg == NULL) { printf("Failed to open file.\n"); } else if(pFile == NULL) { printf("Failed to open file.\n"); printf(pErrorMsg); printf("\n"); } // Deux tests identiques, deux printf identiques, et en plus le test qui décidera si on affiche ou pas pErrorMsg // est un test par omission (au lieu de tester directement pErrorMsg, il teste une autre variable qui lui est appariée mais bon, faut le comprendre quoi) // Ok, là non plus c'est pas super grave. Juste un peu dommage return pFile; }

---

---

Code:

---

1 2 3 4 5 6 7 8

FILE *Filename_OpenFile(char *pFilename, char *pMode, char *pErrorMsg) { FILE *pFile = fopen(pFilename, pMode); // fopen n'admet pas les '\n'. if (pFile == NULL) { printf("Failed to open file.\n"); if (pErrorMsg != NULL) printf("%s\n", pErrorMsg); } return pFile; }

---

Simple is better than complex

Citation:

---

Envoyé par hbx360

Code:

---

1 2 3 4 5 6

char * Filename_RecoveryInputUser(void) { fgets(pFilename, PATH_MAX, stdin); pFilename[strlen(pFilename)-1] = '\0'; // char *pt; if ((pt=strchr(pFilename)) != NULL) *pt='\0' (même résultat mais plus robuste) Keyboard_CleanStdin(); return pFilename; }

---

---

Merci pour ton aide. :D

J'ai modifié la fonction Filename_RecoveryInputUser j'ai mis pFilename en argument, j'espère que c'est mieux.

Code:

---

1 2 3 4 5 6 7 8 9

char * Filename_RecoveryInputUser(char *pFilename) { fgets(pFilename, PATH_MAX, stdin); // Ici je mettrai un teste de réussite. pFilename[strlen(pFilename)-1] = '\0'; // Ok je changerai ça aussi. Keyboard_CleanStdin(); return pFilename; }

---

Entre fgets et pFilename il faudra que je rajoute si j'ai bien compris un test car fgets peu échoué je vois pas bien comment il pourrait renvoyé null mais ok je me servirai de l'ex. de la faq.

Une autre question quand fgets récupère la chaîne est-ce qu'il avance le curseur du buffer clavier ?
Par exemple si je rentre salut et que je lui demande de récupéré 1 caractère (donc 's') est-ce que sa veut dire qu'après dans le buffer le curseurs sera sur 'a et que le 's' sera supprimer ou restera t-il dans le buffer clavier ?

Et quand on appel ensuite CleanStdin est-ce que fgetc (je préfère à getchar) repars du début du buffer ? Donc sur 's' si pas absente.
Est-ce qu'on peut voir le buffer clavier comme un fichier .txt ?

Y a t-il une possibilité de réglé le problème de taper 2 fois entrée.

J'ai énormément de mal à analysé si les programmes que je fais sont pas trop naïf.

Citation:

---

Envoyé par hbx360

J'ai modifié la fonction Filename_RecoveryInputUser j'ai mis pFilename en argument, j'espère que c'est mieux.

---

Oui, tant qu'on peut éviter les globales...

Citation:

---

Envoyé par hbx360

Entre fgets et pFilename il faudra que je rajoute si j'ai bien compris un test car fgets peu échoué je vois pas bien comment il pourrait renvoyé null mais ok je me servirai de l'ex. de la faq.

---

fgets() renvoie NULL quand il n'y a plus rien à lire. Ce qui permet donc de quitter la boucle de lecture (surtout ne pas utiliser feof() pour vérifier qu'on a tout lu car cette fonction ne sert pas à ça)

Citation:

---

Envoyé par hbx360

Une autre question quand fgets récupère la chaîne est-ce qu'il avance le curseur du buffer clavier ?
Par exemple si je rentre salut et que je lui demande de récupéré 1 caractère (donc 's') est-ce que sa veut dire qu'après dans le buffer le curseurs sera sur 'a et que le 's' sera supprimer ou restera t-il dans le buffer clavier ?

---

Heureusement, sinon comment on ferait ?

Citation:

---

Envoyé par hbx360

Est-ce qu'on peut voir le buffer clavier comme un fichier .txt ?

---

Exactement. stdin est identique à tout flux fopen

Citation:

---

Envoyé par hbx360

Y a t-il une possibilité de réglé le problème de taper 2 fois entrée.

---

Faudrait plus de précisions sur ce détail. Quelle fonction tu utilises ? A quel moment ça se produit...

Citation:

---

Envoyé par Sve@r

Y a t-il une possibilité de réglé le problème de taper 2 fois entrée.
Faudrait plus de précisions sur ce détail. Quelle fonction tu utilises ? A quel moment ça se produit...

---

J'utilise les fonctions que j'ai mis plus haut. Quand je rentre au départ sur l'invite de commande le nom du fichier (salut.ass) et que je tape entrée et bien à cause (je pense) de la fonction Keyboard_CleanStdin

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void Keyboard_CleanStdin(void) { s32 c; do { // Note : si on met stdin la console attendra toujours que l'utilisateur tape entrée, que ce soit // fgetc ou fgets pour valider. c = fgetc(stdin); }while(c != '\n' && c !=EOF); }

---

il m'oblige à taper une 2e fois entré je pense que fgetc attends comme fgets (sans doute à cause de stdin) un '\n' pour valider la saisie. J'ai la même chose avec getchar.

Si je ne fait pas CleanStdin, je rentre le nom du fichier puis entrée et je n'ai pas besoin de réappuyer sur entrée.
Sur un de mes message j'ai mis une vidéo.

Citation:

---

Envoyé par hbx360

Si je ne fait pas CleanStdin, je rentre le nom du fichier puis entrée et je n'ai pas besoin de réappuyer sur entrée.
Sur un de mes message j'ai mis une vidéo.

---

Quand je te demande plus de détails, c'est implicitement pour te demander un exemple concret que je puisse copier/coller pour ensuite examiner ce qui se passe, pas des explications à la "je fais comme ci et puis ça marche pas" etc.

Parce que par exemple chez-moi, ça marche nickel

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

#include <stdio.h>   void Keyboard_CleanStdin(void) { char c; do { // Note : si on met stdin la console attendra toujours que l'utilisateur tape entrée, que ce soit // fgetc ou fgets pour valider. c=fgetc(stdin); } while(c != '\n' && c !=EOF); }   int main() { char s[1000]; int n;   printf("Chaine :"); fflush(stdout); scanf("%s", s); Keyboard_CleanStdin(); printf("s=%s\n", s);   printf("Nb :"); fflush(stdout); scanf("%d", &n); Keyboard_CleanStdin(); printf("n=%d\n", n); }

---

Accessoirement, quand on maitrise son clavier, c'est généralement inutile d'utiliser ce genre de fonction.

Voilà un exemple.

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

#include <stdio.h> #include <stdlib.h> #include <stdint.h> // ctypes.h #include <limits.h> // Limits chemin. #include <string.h>     void Keyboard_CleanStdin(void) { int c; do { // Note : si on met stdin la console attendra toujour que l'utilisateur tape entrée, que ce soit // fgetc ou fgets pour valider. c = fgetc(stdin); }while(c != '\n' && c !=EOF); }   char * Filename_RecoveryInputUser(char *pFilename) { fgets(pFilename, PATH_MAX, stdin); pFilename[strlen(pFilename)-1] = '\0'; // A revoir passé par strchr. Keyboard_CleanStdin(); return pFilename; }   FILE *Filename_OpenFile(char *pFilename, char *pMode, char *pErrorMsg) { FILE *pFile = fopen(pFilename, pMode); // fopen n'admet pas les '\n'. if(pFile == NULL) { printf("Failed to open file.\n"); if (pErrorMsg != NULL) printf("%s\n", pErrorMsg); } return pFile; }   void Filename_WaitingTxt(void) { char pInput[2] = {}; int i = 0;   printf("Tapé entrée pour continuer.\n"); fgets(pInput, 2, stdin); Keyboard_CleanStdin();   while( pInput[i] != '\n') { printf("Tapé entrée pour continuer.\n"); fgets(pInput, 2, stdin); Keyboard_CleanStdin(); } }   int main(int argc, char const **argv) { freopen("CON", "w", stdout);   char pFilename[PATH_MAX]; // Buffer pour récupérer la saisie utilisateur. printf("Saisir le nom du fichier.\n"); FILE *pFile = Filename_OpenFile(Filename_RecoveryInputUser(pFilename), "r+", NULL); fclose(pFile);   Filename_WaitingTxt();   return 0; }

---

Ok, là j'ai pu tester.
Donc déjà perso le prompt "entrez le nom du fichier" je le mettrais dans "Filename_RecoveryInputUser". Après-tout, pour une fonction destinée à faire saisir un nom de fichier c'est plutôt normal que ce soit elle qui demande à saisir.
Sinon le souci c'est que Keyboard_CleanStdin est censée vider le buffer stdin. Ce qui sous-entend que stdin contient des trucs à vider. S'il est vide quand tu l'appelles, alors fgetc(stdin) se comporte comme toute fonction attendant une saisie: elle attend la saisie.
Reprenons les choses dans le bon sens: tu appelles une fonction de saisie, ça veut dire que tu as envie qu'elle attende que tu tapes des trucs au clavier. Il se trouve que si le clavier contient déjà des trucs alors elle n'attend pas et récupère directement ces trucs. Ce qui généralement là te fait bien chier d'où le vidage préalable à la saisie. Perso je suis plutôt partisan du "si le clavier contient des trucs c'est que soit ces trucs sont importants et donc il ne faut pas le vider (si par exemple mon programme est placé derrière un pipe, tout stdin sera chargé avec le produit du pipe et donc j'ai pas intérêt à le vider) soit j'ai raté une étape lors de la saisie précédente". Et donc dans tous les cas je n'ai pas à vider stdin.

Maintenant si stdin est vide, alors la fonction se comporte tout à fait normalement et donc attend que tu tapes des trucs. Tu ne peux donc pas lui en vouloir qu'elle attende.
Et quand tu fais saisir le nom du fichier avec fgets(), tu valides cette saisie en appuyant sur <return>. Là se passe alors 2 choses

1. le programme se débloque, n'attend plus rien et continue son job donc tu ne peux plus rentrer des trucs dans stdin
2. fgets() récupère tout jusqu'au '\n' (qui est l'équivalent ascii du <return>) et donc stdin est alors vidé

Et donc au fgetc() suivant, re-attente.

Ok merci pour tes explication. Donc comment résoudre ce problème à part supprimer le vidage du buffer sauf pour la 2e entré.
Parce que j'ai bien essayé de trouvé mais sans succès. J'ai bien l'impression qu'il n'y a pas de solutions.

Citation:

---

Envoyé par hbx360

Parce que j'ai bien essayé de trouvé mais sans succès. J'ai bien l'impression qu'il n'y a pas de solutions.

---

Il n'y a pas de solution parce que surtout il n'y a pas de problème. Quand tu fais saisir une chaine, le '\n' fait partie de la chaine donc il est récupéré et donc ton stdin est toujours vide. Donc pas besoin de le vider.

Eventuellement il pourrait y avoir problème si tu tapes plus de caractères que ce que fgets() a prévu. Dans ce cas, elle s'arrête quand son tampon est plein et laisse le reste dans stdin. Mais dans ce cas, la saisie récupérée ne contient pas de '\n'.
Donc éventuellement si la saisie ne contient pas '\n' là tu peux vider le clavier. Exemple sur Filename_WaitingTxt qui est, dans ta version, aussi bien bancale:

Code:

---

1 2 3 4 5 6 7

void Filename_WaitingTxt(void) { char pInput[2];   printf("Tapé entrée pour continuer.\n"); fgets(pInput, 2, stdin); if (strchr(pInput, '\n') == NULL) Keyboard_CleanStdin(); }

---

Ok, merci bien pour ton aide.

Citation:

---

Eventuellement il pourrait y avoir problème si tu tapes plus de caractères que ce que fgets() a prévu. Dans ce cas, elle s'arrête quand son tampon est plein et laisse le reste dans stdin

---

Pour compléter cette réponse, je dirais que toute la saisie effectuée au clavier est affichée à l'écran, les caractères ne restent pas bloqués quelque part, le buffer stdin est bien vidé.
Par contre, si la saisie dépasse la taille de la chaine passée en paramètre à fgets, ceux-ci ne seront pas stockée dans cette chaine.
Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <stdio.h>   int main() { char buffer[5];   printf("prompt : "); fgets(buffer,3,stdin); printf("valeur chaine buffer : %s",buffer); }

---

Si tu saisie abcdef,
le résultat sera :

Code:

---

1 2 3

dvp@DVP:~/Documents$ ./a.out prompt : abcedf valeur chaine buffer : abdvp@DVP:~/Documents$

---

Tu peux voir qu'il n'y a pas de retour chariot (le prompt du shell est donc collé à la sortie du programme ), \n n'étant pas stockée dans la chaine.
Tu auras un retour chariot uniquement si tu tapes juste a.
pourquoi ? car comme déjà dit le nombre de caractère possible dans la chaine sera égal à size-1 (size étant le second argument attendu par la fonction, dans l'exemple 3-1), il reste donc 2 caractères pouvant être stockés, un pour la lettre a, un pour le retour chariot. La chaine elle occupera 3 octets 'a','\n', et '\0' (le marqueur de fin de chaine représenté par un octet de valeur 0). fgets ajoute un retour chariot à la chaine si sa taille permet de le stocker. Cela peut être gênant d'avoir ce retour chariot, mais c'est le comportement de la fonction et il faut faire avec (par exemple le supprimer en ajoutant du code).

Tu remarqueras aussi que j'ai réservé 5 octets pour buffer. Par rapport à l'utilisation faite, il y a 2 caractères déclarés de trop.

Avec les fonctions chaine, tu n'a pas à te préoccuper de vider stdin. Ce n'est pas le cas avec les fonctions caractères, ou tu peux te retrouver à gérer ce problème en cas d'utilisation de séquences d'échappement.

Merci pour tes explications cela me permettra de mieux comprendre le fonctionnement de fgets et stdin.

Est-ce qu'il y aurai un lien pour pour avoir des précisions sur le fonctionnement de stdin et fgets ?

man fgets devrait te donner ce qu'il faut , à lire attentivement pour bien comprendre les tenants et les aboutissants. fgets sert à lire une chaine de caractères (jusqu'à un retour chariot ou la taille maxi passée à la fonction) dans un flux. On va parler de flux pour les entrées/sortie. Sous sous Unix (et donc Linux) tout est fichier. stdin correspond au descripteur de fichier correspondant au flux d'entrée, sdout correspond au flux de sortie.

Avec ces deux descripteurs de fichiers toujours présents, tu peux piloter la saisie clavier et la sortie console avec les fonctions fichiers (fopen, fclose, fread,fwrite, etc.).

Bien sûr certaines fonctions fonctionnent différemment ou n'ont pas de sens par rapport à un fichier physique. l'utilisation de fseek sur stdin n'a pas de sens et va te générer une erreur "illegal seek".

Ok merci pour ton aide.

J'ai retravaillé mon code et j'ai résolu mon problème en tenant compte de vos conseils.

Normalement ça marche à part pour les accents, dans l'invite de commande avec chcp 65001 c'est ok mais pour l'exécutable bin sa marche pas, il doit surement y avoir une méthode pour modifier le jeu de caractère de l'exécutable.

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 83 84 85 86 87 88 89 90 91 92 93

#include <stdio.h> #include <stdlib.h> #include <limits.h> // Limits chemin. #include <string.h>     void Keyboard_CleanStdin(void) { int c; do { // Note : si on met stdin la console attendra toujour que l'utilisateur tape entrée, que ce soit // fgetc ou fgets pour valider. c = fgetc(stdin); }while(c != '\n' && c !=EOF); }   char * Filename_RecoveryInputUser(char *pFilename) { printf("Saisir le nom du fichier.\n");   if(fgets(pFilename, PATH_MAX+1, stdin) != NULL) { char * LF = strchr(pFilename, '\n'); if(LF != NULL) *LF = '\0'; else Keyboard_CleanStdin(); } return pFilename; }   FILE *Filename_OpenFile(char *pMode, char *pErrorMsg) { char pFilename[PATH_MAX+1]; // Buffer pour récupérer la saisie utilisateur. FILE *pFile = NULL; int nExit = 0;   do { pFile = fopen(Filename_RecoveryInputUser(pFilename), pMode); // fopen n'admet pas les '\n'.   if(pFile == NULL) { printf("Entrée un nom de fichier valide.\n"); if (pErrorMsg != NULL) printf("%s\n", pErrorMsg); nExit = 1; } else { nExit = 0; } }while(nExit); return pFile; }   void Filename_WaitingTxt(void) { char pInput[2] = {}; int i = 0, nExit = 1;   while(nExit) { printf("\n En attente. Tapez entrée pour continuer.\n"); if(fgets(pInput, 2, stdin) != NULL) { char *LF = strchr(pInput, '\n'); if(LF != NULL) { *LF = '\0'; nExit = 0; } else { Keyboard_CleanStdin(); } } } }   int main(int argc, char const **argv) { freopen("CON", "w", stdout);   FILE *pFile = Filename_OpenFile("r+", NULL); fclose(pFile);   Filename_WaitingTxt();   return 0; }

---

Citation:

---

Envoyé par hbx360

Normalement ça marche à part pour les accents, dans l'invite de commande avec chcp 65001 c'est ok mais pour l'exécutable bin sa marche pas, il doit surement y avoir une méthode pour modifier le jeu de caractère de l'exécutable.

---

C'est plus une question d'encoding de la console (je présume que tu fais ça sous console style MsDos) qui n'accepte pas les jeux de caractères étendus (elle est vieille la console MsDos !!!)
En général on laisse pisser parce que d'une part c'est du détail et d'autre part, quand vraiment on veut faire un truc de saisie solide (un truc destiné à un utilisateur lambda) on passe par des IHM style Qt (et en plus on quitte le C vraiment trop long à coder pour passer dans des langages plus riches style C# ou VB ou Python)

Citation:

---

Envoyé par hbx360

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

FILE *Filename_OpenFile(char *pMode, char *pErrorMsg) { char pFilename[PATH_MAX+1]; // Buffer pour récupérer la saisie utilisateur. FILE *pFile = NULL; int nExit = 0;   do { pFile = fopen(Filename_RecoveryInputUser(pFilename), pMode); // fopen n'admet pas les '\n'.   if(pFile == NULL) { printf("Entrée un nom de fichier valide.\n"); if (pErrorMsg != NULL) printf("%s\n", pErrorMsg); nExit = 1; } else { nExit = 0; } } while(nExit); return pFile; }

---

---

Tout programmé bien comme il faut, comme c'est expliqué dans les livres, avec initialisation des variables (bien qu'elles soient remplies ensuite), début de bloc, fin de bloc (même pour les blocs d'une ligne). Et donc programmé bien fade. Ca marche, je dis pas, mais c'est tellement académique que ça en devient... chiant.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

FILE *Filename_OpenFile(char *pMode, char *pErrorMsg) { char pFilename[PATH_MAX+1]; // Buffer pour récupérer la saisie utilisateur. FILE *pFile;   while (1) { pFile = fopen(Filename_RecoveryInputUser(pFilename), pMode); // fopen n'admet pas les '\n'. if (pFile != NULL) break;   printf("Entrée un nom de fichier valide.\n"); if (pErrorMsg != NULL) printf("%s\n", pErrorMsg); } return pFile; }

---

Voilà. Moins de code, moins d'accolades inutiles, moins de "proutprout" et de "flonflon" mais finallement tellement plus léger !!!

Ma mère, qui a fait des compétitions internationales de Bridge (un jeu de carte auquel j'ai jamais rien pané) disait "un bon coup d'oeuil vaut mieux qu'une mauvaise impasse" signifiant qu'on a beau avoir tout un protocole d'annonces pour détailler son jeu à son partenaire (et aussi à ses adversaires), si on peut regarder le jeu du voisin c'est encore mieux. Là c'est un peu pareil. Peut-être que le break c'est le must du mauvais goût dans les écoles d'informatique où les professeurs sont tous bien propres, bien peignés, et savent colorier sans dépasser le bord, mais putain qu'est-ce que ça simplifie le codage !!!

j'ai participé (je ne suis pas étudiant) à des TDs en licence info L2 et le prof (responsable du département informatique de lyon excusé du peu et qui à travaillé aussi dans le monde professionnel) quand il a vue mon code avec des breaks, je me suis fait reprendre, parce que sa ne se fait pas, on ne sort pas proprement avec un break.

J'ai aussi il y a 2 ans, fait une formation développeur web, ont apprenaient le java, je ne m'étais pas de parenthèses dans mes codes avec les if (notamment) quand c'était possible, idem je me faisait reprendre par les formateurs et aussi les autres élèves.

De plus vs code quand je tape un while me met les accolades. Si je dois m'amuser à chaque fois à les enlever c'est relou peut-être y a t-il une option.

Ce qu'il faut comprendre, c'est que malgré le fait que je code en C depuis quelques années, je reste un débutant, un codeur du dimanche. Je n'ai aucune référence pour savoir si un code est bien ou pas j'ai des informations contradictoires qui m'arrive, entre le prof d'info (et les autres prof) qui est une référence qui te dis pas de break, les professionnels qui sont aussi des réf. qui me disent faut mettre un break etc... Moi jsuis perdu.

Ce que je veux, c'est faire du code qui soit propre et acceptable, pour que si un jour je devais montrer mes "réalisations" à un recruteur que j'ai une chance d'avoir un contrat (on rêve mais bon, l'espoir fait vivre...).
De plus je n'ai pas les moyens financier pour demander à un professionnel de corriger mes codes sources ni à un prof. d'info (qui lui me tirerait les oreilles à cause du break).

Sa fait des années que je me creuse la tête pour essayé de faire quelque chose de potable, sans savoir si sa l'ai vraiment. Alors moi qui reste un débutant je fais quoi : j'écoute les gens sur le forum, le prof qui me tombe dessus si tu ne fais pas comme il dit, la faq qui te dis faut faire comme ça, le code source du professionnel qui te met des variables globals alors qu'il faut pas, le gars qui à un niveau doctora et qui passe toutes ses variables en paramètre et sa te fait des fonctions qui font 10 mètres de long, etc.

Tien un autre prof uni qui t'écris les fonctions printf comme ça 1er fois que je vois ça :

Code:

---

1 2	printf("%s","\n");

---

encore une autre

Code:

---

1 2	printf("\n%s %d %s","Entrer la valeur de tab[",i,"] ");

---

Alors jluis dit quoi au prof que c'est la première fois que je vois un truc comme ça et que sur le forum dev.net je ne les aient jamais vue codé comme ça, qui à raison qui à tord qu'elle est la bonne manière de faire ?

Si tu fais comme le prof, sur le forum on peut te tombé dessus, et inversement.

Pas simple. Seul solution se faire embauché dans une boîte pour apprendre à faire de la vrai programmation.

Maintenant je peux vous passé un de mes code source, si vous avez du temps à perdre et vous me le corrigé ou a défaut par l'intermédiaire de commentaires (mis dans le code) me dire ce qui ne va pas et comment vous feriez, vous ; pour moi se serai super intéressant de voir comment en tant que professionnel vous programmer dans vos entreprises, parce que je suppose que pour la majorité, vous êtes des programmeurs professionnels avertis qui avez plusieurs années voir décennie d'expériences derrière vous.

Voilà.

Merci pour tes réponses Sve@r qui mon bien aidé et qui on été instructive pour moi et aussi pour les codes sources que tu mets sa me donne des références et merci aux autres intervenants bien sûr.

Citation:

---

Envoyé par hbx360

j'ai participé (je ne suis pas étudiant) à des TDs en licence info L2 et le prof (responsable du département informatique de lyon escusé du peu) quand il a vue mon code avec des breaks je me suis fait reprendre parce que sa ne se fait pas on ne sort pas proprement avec un break.

---

C'est normal :mrgreen: il y a 2 "esprits". Esprit Kernighan et Ritchie "Single Entry, Single Exit (SESE)" "1 fonction doit avoir 1 et 1 seul return sans break pour les boucles" (le gros trait, ce que je partage :mrgreen:) et ceux qui utilisent tout ce que le langage fourni (comme @Sve@r)

Citation:

---

Envoyé par hbx360

Ce que je veux, c'est faire du code qui soit propre et acceptable si je devais un jour montré mes "réalisation" à un recruteur (on rêve mais bon, l'espoir fait vivre...) et je n'ai pas les moyens financier pour demander à un professionnel de me corrigé mon code source ni à un prof. d'info (qui lui me tirerait les oreilles à cause du break).

---

1 code propre n'existe pas :mrgreen: 1 code fonctionnel par contre lui est essentiel

Et ensuite pour la propreté du code, ce sont des concepts qui ne sont pas de la programmation :

• conception - pour minimiser les appels et l'empreinte mémoire, rendre les communications entre les objets, entre les couches le plus efficace possible, ...
• maintenance - des fonctions avec le moins de code possible, faire du code le plus générique pour minimiser les effets de bords lors des changements, ...
• métrique - empreinte mémoire mais cela peut être aussi la consommation réseau, 3D, ...
• R&D - pour avoir les algos les + performants, les + adaptés par exemple, choix des bibliothèques, ...

Merci pour ta réponse.
Il faudrait que le monde professionnel et académique accorde leurs violons sur la façon de programmer non ?

Ok. Bon déjà on ne te tombe pas dessus (quand je tombe sur quelqu'un sur le forum, il en prend pour son grade). On te donne nos versions des choses. Si ton éditeur rajoute les accolades automatiquement pas besoin de les enlever. Perso à mes débuts j'écrivais comme toi (accolade systématiques en me disant "comme ça si je dois rajouter des instructions les accolades sont déjà là") puis au fur et à mesure que je voyais que je ne rajoutais jamais des instructions j'ai compris que c'était inutile. Les histoires break/pas break ok au début on te fera chier avec mais ça ne t'empêchera pas de te forger ta propre opinion au fur et à mesure que tu coderas. Puis un jour tu seras assez à l'aise pour répondre "arrêtez de me gonfler, mes codes fonctionnent et sont lisibles et c'est ça qui compte" et de là, plus personne ne viendra te casser les noix.

Tu veux faire du code "propre", déjà pense "atomique" (une fonction ne fait qu'une chose mais le fait bien). C'est déjà ce que tu fais avec ta fonction qui fait saisir le nom du fichier et ça c'est bien. Ne perd pas cette approche. Quand tu as un truc à faire, essaye de le découper en étapes importantes et logiques puis affecte une fonction à chaque étape.

Ensuite essaye de séparer "saisie et affichage" d'un côté, "stockage" d'un autre et "calculs" sur le 3°. C'est le principe du MVC: séparer le Modèle (le stockage), la Vue (la saisie/affichage) et le Controleur (calculs). Ca te facilitera les évolutions. Tu pourras alors facilement passer d'un stockage "fichier" à un stockage "bdd" sans toucher le reste, puis d'une saisie "scanf" vers une saisie IHM sans toucher au stockage, etc.

Ok merci pour tes explications.

Citation:

---

Envoyé par foetus

C'est normal :mrgreen: il y a 2 "esprits". Esprit Kernighan et Ritchie "1 fonction doit avoir 1 et 1 seul return sans break pour les boucles" (le gros trait, ce que je partage :mrgreen:)

---

Salut,

As-tu une référence pour étayer ton affirmation ?

Citation:

---

Envoyé par kaitlyn

As-tu une référence pour étayer ton affirmation ?

---

Laquelle d'affirmation ? Le fait que le "un seul return" soit associé à l'esprit "K&R" ou bien que certains préconisent un seul return ?
Pour le "un seul return" c'est recommandé dans certains livres d'ingéniérie de la programmation comme celui-ci qui préconisent le single-entry/single-exit. Sauf qu'ils préconisent sans vraiment dire pourquoi. Un peu dans le style "c'est mieux comme ça faites moi confiance".

Pour l'association "un seul return=K&R" ça j'en sais rien. Toutefois à l'époque de K&R, les ordis savaient moins bien gérer la mémoire qu'aujourd'hui et un seul return permettait de centraliser le point de sortie de la fonction, lequel point de sortie pouvait alors s'occuper aussi de la libération de la mémoire. Une hypothèse pourrait donc être que K&R, informaticiens professionnels, étaient donc parfaitement habitués des méthodes de programmation de l'époque et qu'ils ont fait transpirer cette habitude dans leurs écrits et leurs enseignements. Et peut-être aussi donc que c'est pour ça que cette "légende urbaine" (qui à l'origine avait probablement une raison d'exister, je ne dis pas) continue à perdurer aujourd'hui. Sauf qu'aujourd'hui, les choses ont évolué, il y a le return, le yield, l'exception, le exit et encore plein de technos diverses pour sortir et donc continuer malgré tout ça à professer le "un seul return !!!"...:?

Citation:

---

Envoyé par Sve@r

Pour l'association "un seul return=K&R" ça j'en sais rien.

---

Tu as été plus vite que moi :mrgreen: mais en fait cela vient plus de Edsger W. Dijkstra et encore plus généralement des langages avec 1 gestion des ressources explicite/manuelle comme le C ou l'assembleur

Le terme général est "Single Entry, Single Exit (SESE)" et voici 1 article en anglais "Single Function Exit Point" qui me semble de confiance :mrgreen: