Voilà, j'ai trouvé ce bout de code sur le net :

 
OK, mais un truc me chagrine : comment va-t-on faire pour libérer l'espace mémoire pointé par buffer (alloué par malloc) ?
Pourra-t-on faire un free() de ce pointeur dans un autre fonction ? car là je me dis qu'après plusieurs appels à extensionCPP(), l'occupation mémoire va gonfler, non ?

c'est la fonction appelante qui va devoir libérer la mémoire je suppose... et à part un free du pointeur renvoyer je vois pas vraiment d'autre solution

quand tu appelle ta fonction par :

 
ton pointeur alloué est renvoyé dans la variable szPipo
donc un petit  

 
et hop

vi, un pointeur alloue (enfin la memoire sur laquelle il pointe) par malloc peut etre liberé par malloc dans n'importe quel autre endroit du prog (enfin, sauf dll mais passons).
 

 
mouais au vu de ce que fait ta fonction, deja un sacré d'appel, hein ?

Que je me souvienne bien, c'est bien 25 morts qu'il y a eu la dernière fois (connue) pour 10 octets de fuite ?¿?
 
 
edit : quote merdique

 
Heuh ?  
 
(tain c la tempete de neige ici)

Non mais j'hallucine !! C'est quoi ce code de merde ? On ne doit JAMAIS retourner un pointeur alloué localement, y'a rien de plus crade et de plus dangereux !!!

http://www.programmationworld.com/ [...] numero=109

 
  inutile de tester avant de désallouer. free(NULL) est dans la norme et ne produit rien. Pas de danger donc.

 
  ca ne se caste pas un malloc.

 
Quand on essaye de le faire rentrer dans un char au lieu d'un char*, si.
 
 

 
et ne reviens pas  

 
idem pour le delete du c++ il me semble

je rappelle un ruc sur les cast C. ça revient à dire au compilateur "FERME TA GUEULE"
alors si en plus y en a pas besoin, faut vraiment pas en mettre

C'est juste que c'est pas "propre" où y a une raison technique ?
Les DLL utilisent pourtant le même adressage virtuel, non

 
c'est plus propre, et encore plus si tu as hooké les malloc/free pour tester les fuites memoires
 
de plus, sur certaines plateformes UN*X ou compatibles, le free sur pointeur null c'est pas top top

 
une fonction d'une DLL dans un thread alloue, et la fonction qui libere se retrouve appelée dans un autre thread : bobo    
 
de toute façon, si une fonction doit retourner un buffer, il vaut toujours mieux que l'appellant l'alloue de lui-même pour en garder le controle total
Y a qu'a voir le carnage que ca peut etre dans certaines MFC avec des alloc faites on sait pas trop comment  

 
mauvais compilo, changer compilo. La norme dit qu'on peut le faire sans danger. Si ton compilo ne le permet pas, c'est qu'il ne respecte pas la norme établie par le C. Et donc à priori, tu peux faire n'importe quoi avec ton compilo, ton code généré aura un "comportement indéfini" (bah oui, s'il respecte pas la norme, il peut faire n'importe quoi du coup).

Oui mais dans le monde réél, tu travailles souvent sur des machines que tu n'administres pas
 
Donc je prefere etre trop propre

 
non mais la c'est la norme la plus conne qui soit... c'est comme de dire:
 
"ouais, je prefere réecrire moi meme malloc, c'est pas implémenté sur mon systeme"...
 
mauvais os, changer os.

   
 
p'tet pas exagerer non plus
 
je ne prefere appeler un free que si c'est vraiment necessaire, c'est tout

 
ben 1 malloc = 1 free stout  

Merci à tous pour vos réponses. J'ai aussi ce cas un peu chiant :
insertion d'une cellule à la fin d'une liste chaînée :

 
question 1 : le "+ 1" dans les mallocs est-il nécessaire ?
question 2 : comment va-t-on pouvoir désallouer la mémoire allouée avec malloc() dans les fonctions appellantes ?
 
EDIT : précision supplémentaire : ce bout de code est appellé plein de fois car utilisé dans un service Win2000 (donc prog qui tourne en permanence), d'où la nécessité de libérer de la RAM !

1/ oui, le +1 est necessaire : strlen te donne la taille de la chaine sans le \0 final, donc tu rajoutes 1 pour prendre celui-ci en compte
 
2/ bah c'est simple : comme tout free de liste qui se respecte, tu va parcourir ta liste pour la liberer
Le plus simple est de faire une fonction recursive pour ca :
 
en pseudo code ca donne a peu pres ca :
 
Libere(liste)
{
  si (liste)
  {
    si (liste->suivant) alors Libere(liste->suivant)
    free(liste->champ_de_donnée) // pour chaque champ...
    free(liste)
    liste=null
  }
}

Merci bcp !
si je comprends bien, il est possible de faire "free(ptr)" si le "ptr = malloc(x)" a été fait dans une autre fonction ?

oui, tant que tu ne te balade pas entre plusieurs threads, ou dlls, etc

 
Je vois pas en quoi c'est dangeureux. il suffit de tester à la sortie. Jette un oeil sur les listes et les files. que font les fonctions d'après toi ?

 
Rien à voir, ces fonctions font une allocation sur le heap et non localement. Une variable locale (à une fonction) est désallouée à la fin de la fonction donc il n'est pas possible de la retourner (enfin si, c'est possible mais c'est mal )

Je plussoie Tetragrammaton !
Par définition, une variable allouée localement est détruite à la fin de la fonction. Donc si tu retournes un pointeur non alloué, la zone mémoire à laquelle il fait référence n'existera plus en sortant de la fonction et tu te retrouves avec un pointeur fou, à moins que tu n'alloues la mémoire dans la fonction. Mais ça veut dire que tu dois la libérer en dehors de la fonction, ce qui est dangereux dans le cas d'un projet sur lequel plusieurs personnes travaillent : tu peux être sur que 9 fois sur 10, la RAM ne sera pas libérée.
 
Si on tient absolument à retourner un pointeur, le mieux est de l'allouer avant d'appeler la fonction.

Oui effectivement, que le pointeur soit local ou global ne change rien, la mémoire est toujours allouée sur le tas, thanx God..;-)
Si c'est possible, de facon saine, car ta variable locale est forcément recopiée pour retourner la valeur à l'appelant dans le cadre de la convention de passage de paramètres en vigueur sur le compilo.

On peut faire un truc genre ca pour alloue en dehors de la fonction.