Newsgroup: it.comp.lang.c
Titolo: free()

Ho una funzione come questa:
char *NomeFunzione( int n )
{
char *p;
p = (char *) malloc(sizeOf(char)*255);
/* la funzione a questo punto fa una serie di cose */
...................
...................
....................
......................
/* poi:  */
free(p);
return p;
}
Domanda:
Quant'è che viene liberata la memoria? prima o dopo il return?

 Quant'č che viene liberata la memoria? prima o dopo il return?
Viene liberata durante la chiamata alla free(). E poi tu stai
restituendo un puntatore che non punta piů ad un indirizzo valido. E' un
errore.
EMG

...

Ok, e quindi č corretto chaimare free() dopo return?
 return p;
 free(p);
 }
Ringrazio per l'attenzione

  }
No.
La funzione termina al momento dell'esecuzione dell'istruzione return,
e pertanto il codice inserito dopo return non viene eseguito.
In questo caso la linea di codice "free(p);" non sarà mai eseguita.
Un utilizzo corretto potrebbe essere il seguente:
/* funzione che ritorna un array allocato dinamicamente con malloc */
char* foo (int n)
{
 char* p = (char*)malloc(255*sizeof(char));
 ...
 return p;
}
/* funzione che chiama ed utilizza l'array ritornato da foo() */
void bar ()
{
 char* p = foo(100); /* Chiama foo() e riceve l'array
                        ottenuto con malloc */
 ... /* usa la stringa ritornata da foo() */
 free(p); /* Una volta che la stringa ritornata da foo() non serve
             più, allora si libera la memoria con free() */
}
Spero sia chiaro.
    Il vostro Ermenegildo.

    Il vostro Ermenegildo.


Che coglione la funzione foo() è quella che hai dichiarato sopra il main, ho
risposto subito senza riflettere..... :-)

}
sizeof(char) e' 1 (per definizione di sizeof).
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

  }
Assolutamente no! L'istruzione return provoca l'uscita dalla funzione e
quindi la free() non verrà mai eseguita e la memoria, di conseguenza,
mai rilasciata. A meno che tu non la rilasci dopo da qualche altra parte
del programma...
EMG

sizeof(char) e' 1 (per definizione di sizeof).
E il cast NON serve.
char *p = malloc( 255 ) ;
--
Andrea Laforgia (ICQ 87230455)
"A C program's trick is sometimes a C++ program's trap"
                                          [S.B.Lippman]

conferma di quello che abbiamo pensato, sarebbe meglio.
La conferma e' nella natura stessa del linguaggio.
La cosa, tra l'altro, mi sembra abbastanza intuitiva.


 char *p = malloc( 255 ) ;
Alcuni compilatori C danno un warning per le conversioni
di puntatori da un tipo all'altro, e questo mi da fastidio,
e come effetto collaterale previene possibili errori.
Riguardo l'assunzione sizeof(char) == 1, posso essere
d'accordo, ma preferisco essere sempre esplicito sul
numero elementi/dimensione elemento in malloc.
Credo sia solo una questione di gusti - o c'č qualche
valida ragione per evitare questo tipo di approccio?
Grazie.

valida ragione per evitare questo tipo di approccio?
La ragione e' che, nel caso del cast, e' bene non mascherare al
compilatore eventuali "passa 


 In C NON E' NECESSARIO castare il risultato di malloc.
Purtroppo non tutte le implementazioni del C si attengono
strettamente agli standard. E su alcune piattaforme non hai
la possibilità di sceglierti il compilatore, perché c'è solo
quello (o l'assembly).
E ripeto, per favore leggi meglio quello che ho scritto, che
il warning su certi compilatori C, non perfettamente conformi,
è sulla conversione da puntatore a puntatore e non da int a
puntatore.
E con il lungo andare uno si adatta a scrivere codice che
compila in maniera pulita con tutti i compilatori utilizzati,
quindi mi si perdoni il casting su malloc, o si cambi il
manifesto del newsgroup che inizia così:
"Il gruppo trattera` di qualsiasi dialetto del linguaggio C..."
...e a modifiche fatte, una persona, accorgendosi di utilizzare uno
stile non strettamente conforme agli standard, anche se compatibile
al 100%, non posterà più qui.
Grazie.

al 100%, non posterà più qui.
Bene, che lo faccia da subito, allora.
-- 
Andrea Laforgia (ICQ# 87230455) ---------------------------
Non scrivetemi in privato, se non richiesto espressamente.
No replies in private e-mail, unless explicitly requested.
----------------------------------------------------------