Un monte di correzioni fatte su indicazioni di Mirko Maischberger.

[gapil.git] / process.tex

diff --git a/process.tex b/process.tex
index c5f9187743a3da98a40164f0fd77c047295df12d..b484b17501d8713af29616ad8fe1e6e0034ed41f 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -555,8 +555,8 @@ tollerante nei confronti di piccoli errori come quello di chiamate doppie a
 
 Il problema più comune e più difficile da risolvere che si incontra con le
 routine di allocazione è quando non viene opportunamente liberata la memoria
 
 Il problema più comune e più difficile da risolvere che si incontra con le
 routine di allocazione è quando non viene opportunamente liberata la memoria

-non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak},
-cioè una \textsl{perdita di memoria}.
+non più utilizzata, quello che in inglese viene chiamato \textit{memory
+  leak}\index{memory leak}, cioè una \textsl{perdita di memoria}.

 
 Un caso tipico che illustra il problema è quello in cui in una subroutine si
 alloca della memoria per uso locale senza liberarla prima di uscire. La
 
 Un caso tipico che illustra il problema è quello in cui in una subroutine si
 alloca della memoria per uso locale senza liberarla prima di uscire. La


@@ -569,7 +569,7 @@ Il problema 
 momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
 essere in una sezione del codice che non ha alcuna relazione con la subroutine
 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
 momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
 essere in una sezione del codice che non ha alcuna relazione con la subroutine
 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un

-\textit{memory leak}.
+\textit{memory leak}\index{memory leak}.

 
 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
 programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
 
 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
 programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente


@@ -615,10 +615,10 @@ molto complesse riguardo l'allocazione della memoria.
 \label{sec:proc_mem_alloca}
 
 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
 \label{sec:proc_mem_alloca}
 
 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei

-problemi di \textit{memory leak} descritti in precedenza, è la funzione
-\funcd{alloca}, che invece di allocare la memoria nello heap usa il segmento
-di stack della funzione corrente. La sintassi è identica a quella di
-\func{malloc}, il suo prototipo è:
+problemi di \textit{memory leak}\index{memory leak} descritti in precedenza, è
+la funzione \funcd{alloca}, che invece di allocare la memoria nello heap usa
+il segmento di stack della funzione corrente. La sintassi è identica a quella
+di \func{malloc}, il suo prototipo è:

 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
   Alloca \param{size} byte nello stack.
   
 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
   Alloca \param{size} byte nello stack.
   


@@ -634,10 +634,10 @@ quindi non esiste un analogo della \func{free}) in quanto essa viene
 rilasciata automaticamente al ritorno della funzione.
 
 Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
 rilasciata automaticamente al ritorno della funzione.
 
 Come è evidente questa funzione ha molti vantaggi, anzitutto permette di

-evitare alla radice i problemi di memory leak, dato che non serve più la
-deallocazione esplicita; inoltre la deallocazione automatica funziona anche
-quando si usa \func{longjmp} per uscire da una subroutine con un salto non
-locale da una funzione (vedi \secref{sec:proc_longjmp}).
+evitare alla radice i problemi di memory leak\index{memory leak}, dato che non
+serve più la deallocazione esplicita; inoltre la deallocazione automatica
+funziona anche quando si usa \func{longjmp} per uscire da una subroutine con
+un salto non locale da una funzione (vedi \secref{sec:proc_longjmp}).

 
 Un altro vantaggio è che in Linux la funzione è molto più veloce di
 \func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
 
 Un altro vantaggio è che in Linux la funzione è molto più veloce di
 \func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un


@@ -1581,7 +1581,7 @@ un punto precedentemente stabilito con \func{setjmp} si usa la funzione
 \end{functions}
 
 La funzione ripristina il contesto dello stack salvato da una chiamata a
 \end{functions}
 
 La funzione ripristina il contesto dello stack salvato da una chiamata a

-\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione
+\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione il

 programma prosegue nel codice successivo al ritorno della \func{setjmp} con
 cui si era salvato \param{env}, che restituirà il valore \param{val} invece di
 zero.  Il valore di \param{val} specificato nella chiamata deve essere diverso
 programma prosegue nel codice successivo al ritorno della \func{setjmp} con
 cui si era salvato \param{env}, che restituirà il valore \param{val} invece di
 zero.  Il valore di \param{val} specificato nella chiamata deve essere diverso


@@ -1631,7 +1631,7 @@ e statiche mantengono i valori che avevano al momento della chiamata di
 Quello che succede infatti è che i valori delle variabili che sono tenute in
 memoria manterranno il valore avuto al momento della chiamata di
 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
 Quello che succede infatti è che i valori delle variabili che sono tenute in
 memoria manterranno il valore avuto al momento della chiamata di
 \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella

-chiamata ad un'altra funzioni vengono salvati nel contesto nello stack)
+chiamata ad un'altra funzione vengono salvati nel contesto nello stack)

 torneranno al valore avuto al momento della chiamata di \func{setjmp}; per
 questo quando si vuole avere un comportamento coerente si può bloccare
 l'ottimizzazione che porta le variabili nei registri dichiarandole tutte come
 torneranno al valore avuto al momento della chiamata di \func{setjmp}; per
 questo quando si vuole avere un comportamento coerente si può bloccare
 l'ottimizzazione che porta le variabili nei registri dichiarandole tutte come