Discussion:Programmation C/Entrées/sorties

Problèmes dans exemple

Bonjour

Dans le chapitre entrées non formatées, je lis :

Un exemple de lecture de ligne arbitrairement longue est vu plus bas...

L'exemple incorrect

L'exemple incorrect

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

/**
 * lire_ligne tente de lire une ligne entiere depuis le flux.
 * Le '\n' final est enlevé.
 *
 * Si la ligne est vide, la fonction renvoie un pointeur vers
 * une chaîne contenant uniquement '\0' et place errno à 0.
 * 
 * Si une erreur intervient au début de la lecture,
 * la fonction renvoie NULL et place errno à 1.
 *
 * Si une erreur intervient après qu'au moins un caractère a été lu, 
 * la fonction renvoie ce qui a été lu, et place errno à 1.
 *
 * En cas de succès, errno est placé à 0.
 */
char *lire_ligne(FILE *flux)
{
    int taille = 256;
    char *chaine = malloc(taille);
    errno = (chaine == NULL);
    if (chaine != NULL)
    {
        int i = 0;
        int c;
        while ((c = fgetc(stdin)) != EOF)
        {
            if (i == taille)
            {
                /* Le tableau est plein, et on a encore des choses a lire... */
                taille += 256;
                char *nouvelle = realloc(chaine, taille);
                if (nouvelle == NULL)
                {
                    errno = 1;
                    break;
                }
                chaine = nouvelle;
            }
            if (c != '\n')
            {
                chaine[i] = c;
                i++;
            }
            else
            {
                /* fin de la ligne: on s'arrete sans mettre le '\n' */
                break;
	    }
        }
        chaine[i] = '\0';
    }
    return chaine;
}

Mes remarques

1. A quoi sert #include <string.h> ?
2. A quoi sert l'argument FILE *flux ? La fonction ne lit que dans stdin fgetc(stdin).
3. Utiliser errno à droite dans une affectation pour retourner des valeurs perso me parait risqué : errno = (chaine == NULL);. Le système initialise errno à ENOMEM pour un problème sur malloc ou realloc, pourquoi ne pas s'en servir ? Une initialisation de errno à 1, correspond à une erreur système EPERM : Operation not permitted. L'emploi de perror dans l'appelant affichera un mauvais diagnostique d'erreur.
4. Pourquoi utiliser fgetc au lieu de fgets, quitte à appeler plusieurs fois fgets si la ligne est trop longue pour le buffer chaine ?
5. L'utilisation de break dans une boucle est déconseillée.
6. La mémoire est allouée. Pour éviter les fuites mémoires, l'appelant devra la libérer. Cela devrait être stipulé dans les commentaires d'entête.
7. Comment sait-on si avec avec fgetc on a rencontré une fin de fichier ou ou erreur ?
8. Si dans la boucle (i == taille-1) et (c != '\n'), on incrémente i qui vaut taille, si à l'itération suivante fgetc retourne EOF, on sort de la boucle. L'instruction chaine[i] = '\0'; adresse chaine[taille]. chaine a des indices valides de 0 à taille-1. Cette instruction ècrit en dehors du tableau. Il y a du SIGSEGV (violation d'espace d'adressage) dans l'air. Il faut toujours imaginer le pire.
9. La constante littérale 256 devrait être remplacée par une constante symbolique.
10. malloc et realloc attendent un argument de type size_t, on leur passe taille de type int.
11. La déclaration char *nouvelle devrait être en premier dans son bloc.
12. Les expressions idiomatiques C errno = (chaine == NULL); et taille += 256; peuvent être difficiles à comprendre par un autre programmeur chargé de la maintenance et non habitué à cette syntaxe spécifique du C.
13. Pourquoi ne pas déclarer le paramètre de cette fonction : FILE * restrict flux ?
14. Pourquoi ne pas fournir un programme main appelant pour tester cette fonction ?

Ma solution

Exercices en langage C/Fonctions#Lire une ligne longue avec fgets

--Thierry46 2 février 2008 à 07:33 (CET)