Discussion :

[lefevrer]

Bonjour à tous,

Je vais aborder un sujet qui a déjà été abordé des centaines de fois. Malheureusement, je ne trouve pas ma réponse, où en tout cas pas celle qui me convienne.

Voici le code en question:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
string1 = malloc ( nb_char * sizeof(*string1));
if( string1 == NULL ) 
{
     fprintf(stderr,"malloc failed in file:%s line : %s",__FILE__,__LINE__);
     exit(EXIT_FAILURE);
}
 
string2 = malloc ( nb_char * sizeof(*string2));
if( string2 == NULL ) 
{
     fprintf(stderr,"malloc failed in file:%s line : %s",__FILE__,__LINE__);
     exit(EXIT_FAILURE);
}
 
free(string1); 
string1 = NULL;
 
free(string2); 
string2 = NULL;

Je pense que tout le monde est d'accord avec les lignes que j'ai écrit ci-dessus. A propos, les lignes ci-dessous n'ont été écrites que pour illustrer mon problème.

Si le programme, se passe normalement, il n'y a pas de problème. Si le programme n'arrive pas à allouer la mémoire au premier malloc(), il y a une erreur ce qui est normale. Mais si le programme rencontre un problème au deuxième malloc(), il y a une erreur ce qui est normale, mais la memoire allouée pour le premier malloc() n'est jamais libérée.

Vous me direz je n'ai qu'à écrire:

Code :

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

1
2
3
 
free(string1); 
string1 = NULL;

juste avant

Code :

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

1
2
 
exit(EXIT_FAILURE);

de mon deuxième malloc(). Et je suis d'accord avec vous. Mais cette méthode est bien quand on a un petit programme. Si on a beaucoup de variables allouées dynamiquement dans un gros programme, cela devient ingérable. J'aimerais donc savoir si vous avez une astuce, une méthode, ou quoique cela soit pour éviter ce genre de problème.

[BainE]

Bonjour,

y en a qui utilise les goto notamment pour ce genre de souci, mais peut rien que cette ligne va relancer le debat houleux sur le goto. Perso pas trop pour non plus (voir pas du tout).

Sinon ben oui, avant de sortir tu liberes.

Sinon 3eme approche si tu rates ton allocation, peut etre va tu terminer le prog ? du coup la memoire est liberee quand le systeme termine le prog.

Et 4eme .. heu ... je vois pas sur le coup mais y a ptet aussi.

Pour conclure oui le C c'est contraignant, par contre une autre question es tu oblige d'utiliser l allocation dynamique ?

[Obsidian]

y en a qui utilise les goto notamment pour ce genre de souci, mais peut rien que cette ligne va relancer le debat houleux sur le goto. Perso pas trop pour non plus (voir pas du tout).

Le débat en question se tient ici : http://www.developpez.net/forums/d75...c/pensez-goto/ . Personnellement, je milite pour une réhabilitation du goto dans de bonnes conditions, parce qu'effectivement, tout le monde a mis le saut inconditionnel à l'index mais plus personne ne sait pourquoi.

[nicolas.sitbon]

Sinon 3eme approche si tu rates ton allocation, peut etre va tu terminer le prog ? du coup la memoire est liberee quand le systeme termine le prog.

Tu as le passage dans la norme qui appuie ce que tu dis?

[BainE]

Ben c'est pas du C a ce niveau, mais c'est vrai que ma reponse est incomplete.

A verifier si le systeme le fait, mais ce qui du coup supprime la caractere portable proprement

En fait, faudrait regarder s'il existe encore des systemes qui ne le font pas, a part en embarque (je considere preemptoirement qu un soft est pour de l embarque ou du "fixe") ou la je libererai explicitement avant de sortir.

[Thierry Chappuis]

Sinon 3eme approche si tu rates ton allocation, peut etre va tu terminer le prog ? du coup la memoire est liberee quand le systeme termine le prog.

Pourquoi vouloir procéder de la sorte, alors qu'on peut faire quelque chose de propre avec un peu de structure dans son code. Par ailleurs, rien ne garantit à priori que la mémoire sera libérée à la fin de l'exécution d'un programme (bien que ce soit en principe le cas sur le peu de systèmes que je connaisse).

@lefevrer: QU'est-ce qui ne te convient pas dans la solution proposée ici: http://www.developpez.net/forums/m3588213-10/

Thierry

[contremaitre]

Salut

je te conseille la lecture de cette discussion qui t'aportera surement des solutions :
http://www.developpez.net/forums/d49...sieurs-malloc/

[PadawanDuDelphi]

Salut,

En C, une méthode classique est de reporter la gestion des erreur en fin de fonctions, avec par exemple une macro qui teste les valeurs de retour de tes fonctions et renvoi à un label en cas d'erreur, du style (dans le cas ou tes fonctions renvoient un entier négatif en cas d'erreur:

Code :

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

#define fERR(fonction) if (erreur = (fonction), error < 0) {goto Erreurr;}

Et ensuite tu gère des libérations, tes affichages de messages d'erreur à la suite du label:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int aFonction(void)
{
int erreur =0;
 
// Ton code
fERR( fprintf(stderr,"malloc failed in file:%s line : %s",__FILE__,__LINE__) );
// Ton code
 
Erreur:
  if (error<0)
  {
     if (string1 != NULL)
    {
        free(string1); 
       string1 = NULL;
    }
  }
  return erreur;
}

Et en général il vaut mieux eviter la fonction exit(), qui est une méthode un peu bourrine à mon sens.

A+.

[BainE]

En precisant que "methode classique" ne veut pas dire "bonne methode"

[PadawanDuDelphi]

En precisant que "methode classique" ne veut pas dire "bonne methode"

Effectivemment, je donnait simplement ma méthode de programmeur semi-amateur... Et par respect envers les antis-goto (nombreux et dont je fais parti d'habitude), j'irai jamais dire que c'est la bonne méthode...C'est une méthode parmi d'autres.

[Emmanuel Delahaye]

Mais cette méthode est bien quand on a un petit programme. Si on a beaucoup de variables allouées dynamiquement dans un gros programme, cela devient ingérable. J'aimerais donc savoir si vous avez une astuce, une méthode, ou quoique cela soit pour éviter ce genre de problème.

Si tu quittes le programme en faisant exit() le problème de la libération de la mémoire ne se pose pas, car une sortie par exit() (ou return dans main()), libère la mémoire et ferme les fichiers.

Mais c'est quand même assez cracde de coder des exit() en plein milieu du code et surtout, le jour où ce code passe en bibliothèque, les comportement devient carrément insupportable (une fonction de bibliothèque qui arrête l'exécution, non mais de quoi je même l).

Bref, comme souvent, c'est au niveau de la conception que les Bonnes Pratiques doivent être mises en oeuvre. Je recommande notamment l'usage des 'constructeurs / desctruteurs' pour les objets un peu complexes (ce que fait le langage C avec FILE), selon le schéma suivant

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
obj_s *p = obj_create();
 
if (p != NULL)
{
    /* usage de p */
 
    obj_delete (p), p = NULL;
}
else
{
   /* erreur */
}

Si on applique ce schéma a tous les objets dynamiques de l'application[1], il n'y a pas de problèmes de libération de mémoire, et le code devient facilement réutilisable.


http://emmanuel-delahaye.developpez.com/tad.htm
http://emmanuel-delahaye.developpez.com/complog.htm
http://emmanuel-delahaye.developpez.com/clib.htm


-----------------
[1] encore une fois, je n'ai rien inventé, FILE fonctionne comme ça : créateur : fopen()
destructeur : fclose()

[lefevrer]

@Thierry Chapuis: ta réponse ne me convient pas car elle ne libère la memoire de string1 dans le cas d'une erreur dans l'allocation de string2. Donc je pense que tu as oublie un

Code :

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

free(string1), string1 = NULL;

avant le premier

Code :

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

1
2
fprintf(stderr,"malloc failed in file:%s line : %s",__FILE__,__LINE__);
        exit(EXIT_FAILURE);

Et en réalité cette solution ne me convient pas car j'utilise les macros définis ici. Donc je ne peux pas y insérer la libération de string1 par exemple.

@Emmanuel Delahaye: Je ne sais pas ce que fait exit(). Mais c'est un linux embarqué, donc je pense que c'est la même chose qu'un linux normal. De plus, je comprend parfaitement le problème du exit. Je vais donc le changer par un return ce qui me permet de remonter l'erreur comme me l'a sugéré Thierry Chapuis. De plus, mon programme n'est pas fait pour tourner en permanence (en tout cas pas pour le moment). Enfin, mon problème de gestion n'apparaît qu'à la fermeture du programme. Donc si un exit() ou un return() libère la mémoire plus de problème. Mais nicolas.sitbon n'a pas l'air d'être d'accord avec ce point!

[BainE]

En meme temps si c est pour devenir un code qui doit tourner toute une journée... je pense que la reponse est dans la question.

Laisser le systeme recuperer la memoire me semble viable pour un petit prog qui fait son action et se termine.

[lefevrer]

Ok, je vous remercie pour vos réponses. Je vais faire confiance à l'OS pour la libération de la mémoire en qu'à d'erreur (et que dans ce cas...)

[Thierry Chappuis]

@Thierry Chapuis: ta réponse ne me convient pas car elle ne libère la memoire de string1 dans le cas d'une erreur dans l'allocation de string2.

Tu as raison, j'ai corrigé mon post.

Thierry

[nicolas.sitbon]

Tu es sur un linux embarqué :ok
Quel noyau?
Quellle architecture?
Quelle bibliothèque standard du C?

En fonction de ta réponse viendront les solutions.

[lefevrer]

Je crois que la version du noyau est 2.6.26. L'architecture est ARMv4. Et la bibliothèque standard du C... j'en sais rien.