Completata la descrizione dell'esempio dei mutex realizzati con i semafori.
[gapil.git] / process.tex
index 9cf5f86..67cb4f5 100644 (file)
 \chapter{L'interfaccia base con i processi}
 \label{cha:process_interface}
 
-Come accennato nell'introduzione il processo è l'unità di base con cui un
-sistema unix alloca ed utilizza le risorse.  Questo capitolo tratterà
-l'interfaccia base fra il sistema e i processi, su come vengono passati i
-parametri, come viene gestita e allocata la memoria, su come un processo può
-richiedere servizi al sistema, su cosa deve fare quando ha finito la sua
-esecuzione.
+Come accennato nell'introduzione il \textsl{processo} è l'unità di base con
+cui un sistema unix-like alloca ed utilizza le risorse.  Questo capitolo
+tratterà l'interfaccia base fra il sistema e i processi, come vengono passati
+i parametri, come viene gestita e allocata la memoria, come un processo può
+richiedere servizi al sistema e cosa deve fare quando ha finito la sua
+esecuzione. Nella sezione finale accenneremo ad alcune problematiche generiche
+di programmazione.
 
 In genere un programma viene eseguito quando un processo lo fa partire
-eseguendo una funzione della famiglia \texttt{exec}; torneremo su questo e
-sulla la creazione e gestione dei processi nel prossimo capitolo, in questo
+eseguendo una funzione della famiglia \func{exec}; torneremo su questo e sulla
+creazione e gestione dei processi nel prossimo capitolo. In questo
 affronteremo l'avvio e il funzionamento di un singolo processo partendo dal
-punto di vista del programma posto in esecuzione.
-
+punto di vista del programma che viene messo in esecuzione.
 
 
 \section{Esecuzione e conclusione di un programma}
 
-Una delle concetti base relativi ai processi è che un processo esegue sempre
-uno ed un solo programma: si possono avere più processi che eseguono lo stesso
-programma ma ciascun processo vedrà la sua copia del codice (in realtà il
-kernel fa si che tutte le parti uguali siano condivise) avrà un suo spazio di
-indirizzi, variabili proprie e sarà eseguito in maniera completamente
-indipendente da tutti gli altri. 
-
-Anche quando all'interno di un programma possono essere presenti più
-\textsl{filoni} di esecuzione (i cosiddetti \textit{thread}), o questo possa
-essere composto da moduli multipli completamente separati, quando questo sarà
-posto in esecuzione esso apparirà al sistema come un solo processo (il
-discorso dei \textit{thread} comunque in Linux necessita di una trattazione a
-parte per la peculiarità dell'implementazione).
-
-\section{La funzione \texttt{main}} 
+Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo
+programma: si possono avere più processi che eseguono lo stesso programma ma
+ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
+tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
+variabili proprie e sarà eseguito in maniera completamente indipendente da
+tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
+  \textit{multi-thread}, ma la gestione dei \textit{thread} in Linux sarà
+  trattata a parte.}
+
+
+\subsection{La funzione \func{main}} 
 \label{sec:proc_main}
 
-Quando un programma viene lanciato il kernel esegue unopportuna routine di
-avvio, usando il programma \texttt{ld-linux.so}, è questo programma che prima
-carica le librerie condivise che servono al programma, effettua il link
-dinamico del codice e poi alla fine lo esegue. Infatti, a meno di non aver
-specificato il flag \texttt{-static} durante la compilazione, tutti i
-programmi in Linux sono incompleti e necessitano di essere linkati alle
-librerie condivise quando vengono avviati.  La procedura è controllata da
-alcune variabili di ambiente e dal contenuto di \texttt{/etc/ld.so.conf}, i
-dettagli sono riportati nella man page di \texttt{ld.so}.
-
-Il sistema fa partire qualunque programma chiamando la funzione \texttt{main};
+Quando un programma viene lanciato il kernel esegue un'opportuna routine di
+avvio, usando il programma \cmd{ld-linux.so}.  Questo programma prima carica
+le librerie condivise che servono al programma, poi effettua il link dinamico
+del codice e alla fine lo esegue. Infatti, a meno di non aver specificato il
+flag \texttt{-static} durante la compilazione, tutti i programmi in Linux sono
+incompleti e necessitano di essere linkati alle librerie condivise quando
+vengono avviati.  La procedura è controllata da alcune variabili di ambiente e
+dal contenuto di \file{/etc/ld.so.conf}. I dettagli sono riportati nella man
+page di \cmd{ld.so}.
+
+Il sistema fa partire qualunque programma chiamando la funzione \func{main};
 sta al programmatore chiamare così la funzione principale del programma da cui
-si suppone iniziale l'esecuzione; in ogni caso senza questa funzione lo stesso
+si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
 linker darebbe luogo ad errori.
 
-Lo standard ISO C specifica che la funzione \texttt{main} può o non avere
+Lo standard ISO C specifica che la funzione \func{main} può non avere 
 argomenti o prendere due argomenti che rappresentano gli argomenti passati da
 linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
-\begin{verbatim}
-     int main (int argc, char *argv[])
-\end{verbatim}
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+    int main (int argc, char *argv[])
+\end{lstlisting}
 
-In realtà nei sistemi unix esiste un'altro modo per definire la funzione
-\texttt{main}, che prevede la presenza di un terzo parametro, \texttt{char
-  *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{proc_environ}) del
-programma; questa forma però non è prevista dallo standard POSIX.1 per cui se
-si vogliono scrivere programmi portabili è meglio evitarla.
+In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
+\func{main}, che prevede la presenza di un terzo parametro, \var{char
+  *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ})
+del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
+se si vogliono scrivere programmi portabili è meglio evitarla.
 
 
 \subsection{Come chiudere un programma}
-\label{sec:proc_termination}
+\label{sec:proc_conclusion}
 
-La via normale per la quale un programma finisce è quando la funzione main
-ritorna, una modalità equivalente di conclusione è quella di chiamare
-direttamente la funzione \texttt{exit} (che viene comunque chiamata dalla
-routine di avvio del programma quando la funzione main ritorna). Una forma
-alternativa è quella di chiamare direttamente la system call \texttt{\_exit}
-che passa il controllo direttamente al kernel.
+Normalmente un programma finisce quando la funzione \func{main} ritorna, una
+modalità equivalente di chiudere il programma è quella di chiamare
+direttamente la funzione \func{exit} (che viene comunque chiamata
+automaticamente quando \func{main} ritorna).  Una forma alternativa è quella
+di chiamare direttamente la system call \func{\_exit}, che restituisce il
+controllo direttamente alla routine di conclusione dei processi del kernel.
 
 Oltre alla conclusione ``normale'' esiste anche la possibilità di una
-conclusione ``anomala'' del programma a causa di segnali o della chiamata alla
-funzione \texttt{abort} (che comunque genera un segnale che termina il
-programma); torneremo su questo in \secref{sec:sig_abort}.
-
-Il valore di ritorno della funzione main, o quello usato nelle chiamate ad
-\texttt{exit} e \texttt{\_exit}, viene chiamato \textit{exit status} e passato
-al processo padre che aveva lanciato il programma (in genere la shell). In
-generale si usa questo valore per fornire un'informazione generica sulla
-riuscita o il fallimento del programma; l'informazione è necessariamente
-generica, ed il valore deve essere compreso fra 0 e 255.
-
-In generale si usa la convenzione di restituire 0 in caso di successo e 1 in
-caso di fallimento, i programmi che effettuano dei confronti (come
-\texttt{diff}) usano invece una notazione leggermente diversa, usando 0 per
-indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
-indicare l'incapacità di effettuare il confronto. È opportuno adottare una di
-queste convenzioni a seconda dei casi. Si tenga presente che se si raggiunge
-la fine della funzione \texttt{main} senza ritornare esplicitamente si ha un
-valore di uscita indefinito, è pertanto consigliabile di concludere sempre in
-maniera esplicita detta funzione.
-
-Una altra convenzione riserva i valori da 128 in su per usi speciali, ad
+conclusione ``anomala'' del programma a causa della ricezione di un segnale
+(si veda \capref{cha:signals}) o della chiamata alla funzione \func{abort};
+torneremo su questo in \secref{sec:proc_termination}.
+
+Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate
+ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
+\textit{exit status}) e passato al processo che aveva lanciato il programma
+(in genere la shell). In generale si usa questo valore per fornire
+informazioni sulla riuscita o il fallimento del programma; l'informazione è
+necessariamente generica, ed il valore deve essere compreso fra 0 e 255.
+
+La convenzione in uso pressoché universale è quella di restituire 0 in caso di
+successo e 1 in caso di fallimento; l'unica eccezione è per i programmi che
+effettuano dei confronti (come \cmd{diff}), che usano 0 per indicare la
+corrispondenza, 1 per indicare la non corrispondenza e 2 per indicare
+l'incapacità di effettuare il confronto. È opportuno adottare una di queste
+convenzioni a seconda dei casi.  Si tenga presente che se si raggiunge la fine
+della funzione \func{main} senza ritornare esplicitamente si ha un valore di
+uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
+esplicita detta funzione.
+
+Un'altra convenzione riserva i valori da 128 a 256 per usi speciali: ad
 esempio 128 viene usato per indicare l'incapacità di eseguire un altro
-programma in un sottoprocesso. Benché anche questa convenzione non sia
+programma in un sottoprocesso. Benché questa convenzione non sia
 universalmente seguita è una buona idea tenerne conto.
 
-Si tenga presente inoltre che non è una buona idea usare il valore dell'errore
-restituito dalla variabile \texttt{errno} come stato di uscita, in generale
-una shell non si cura di tutto questo e comunque il valore dello stato di
-uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in
-cui l'errore 256, diventando zero, verrebbe interpretato come un successo. In
-\texttt{stdlib.h} sono definite due macro \texttt{EXIT\_SUCCESS} e
-\texttt{EXIT\_FAILURE}, che in Linux sono poste rispettivamente ai valori 0 e
-1 (di tipo \texttt{int}), seguendo lo standard POSIX.
-
-Infine occorre distinguere fra lo stato di uscita di un programma
-(l'\textit{exit status}) e lo stato di conclusione di un processo (il
-\textit{termination status}), abbiamo già accennato infatti che è comunque
-possibile un processo possa essere terminato (da un segnale) prima che il
-programma in esecuzione si sia concluso. In caso di conclusione normale del
-programma però lo stato di uscita diventa parte dello stato di conclusione del
-processo (vedi \secref{sec:prochand_XXX}).
-
-
-\subsection{Le funzioni \texttt{exit} e \texttt{\_exit}}
+Si tenga presente inoltre che non è una buona idea usare il codice di errore
+restituito dalla variabile \var{errno} (per i dettagli si veda
+\secref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
+non si cura del valore se non per vedere se è diverso da zero; inoltre il
+valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
+incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
+uno stato di uscita uguale a zero, che verrebbe interpretato come un successo.
+
+In \file{stdlib.h} sono definite, seguendo lo standard POSIX, le due macro
+\macro{EXIT\_SUCCESS} e \macro{EXIT\_FAILURE}, da usare sempre per specificare
+lo stato di uscita di un processo. In Linux esse sono poste rispettivamente ai
+valori di tipo \ctyp{int} 0 e 1.
+
+
+\subsection{Le funzioni \func{exit} e \func{\_exit}}
 \label{sec:proc_exit}
 
-Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la
-prima è la funzione \texttt{exit} che è definita dallo standard ANSI C, il
-prototipo della funzione è il seguente:
+Come accennato le funzioni usate per effettuare un'uscita ``normale'' da un
+programma sono due, la prima è la funzione \func{exit} che è definita dallo
+standard ANSI C ed il cui prototipo è:
 \begin{prototype}{stdlib.h}{void exit(int status)}
   Causa la conclusione ordinaria del programma restituendo il valore
-  \texttt{status} al processo padre.
+  \var{status} al processo padre.
 
-  La funzione non ritorna. Il processo viene terminato
+  \bodydesc{La funzione non ritorna. Il processo viene terminato.}
 \end{prototype}
 
-La funzione \texttt{exit} è pensata per una conclusione pulita di un programma
-che usa le librerie standard del C; essa esegue tutte le funzioni che sono
-state registrate con \texttt{atexit} e \texttt{on\_exit} (vedi
-\secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il
-salvataggio dei dati sospesi (chiamando \texttt{fclose}, vedi
-\secref{sec:filestd_close}), infine ripassa il controllo al kernel chiamando
-\texttt{\_exit} e passando il valore \texttt{status} come stato di uscita.
-
-La system call \texttt{\_exit} restituisce direttamente il controllo al
-kernel, concludendo immediatamente il processo, le eventuali funzioni
-registrate con \texttt{atexit} e \texttt{on\_exit} non vengono eseguite. Il
-prototipo della funzione è il seguente:
+La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
+programma che usi le librerie standard del C; essa esegue tutte le funzioni
+che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
+\secref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
+salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
+\secref{sec:file_fopen}), infine passa il controllo al kernel chiamando
+\func{\_exit} e passando \param{status} come stato di uscita.
+
+La system call \func{\_exit} restituisce direttamente il controllo al kernel,
+concludendo immediatamente il processo; i dati sospesi nei buffer degli stream
+non vengono salvati e le eventuali funzioni registrate con \func{atexit} e
+\func{on\_exit} non vengono eseguite. Il prototipo della funzione è:
 \begin{prototype}{unistd.h}{void \_exit(int status)}
-  Causa la conclusione immediata del programma restituendo il valore
-  \texttt{status} al processo padre.
+  Causa la conclusione immediata del programma restituendo \param{status} al
+  processo padre come stato di uscita.
 
-  La funzione non ritorna. Il processo viene terminato.
+  \bodydesc{La funzione non ritorna. Il processo viene terminato.}
 \end{prototype}
 
-La funzione chiude tutti i file descriptor appartenenti al processo (sui tenga
+La funzione chiude tutti i file descriptor appartenenti al processo (si tenga
 presente che questo non comporta il salvataggio dei dati bufferizzati degli
-stream), fa si che ogni figlio del processo sia ereditato da \texttt{init}
-(vedi \secref{cha:process_handling}), manda un segnale \texttt{SIGCHLD} al
-processo padre (vedi \ref{sec:sig_sigchild}) ed infine ritorna lo stato di
-uscita specificato in \texttt{status} che può essere raccolto usando la
-funzione \texttt{wait} (vedi \secref{sec:prochand_wait}).
+stream), fa sì che ogni figlio del processo sia ereditato da \cmd{init} (vedi
+\secref{cha:process_handling}), manda un segnale \macro{SIGCHLD} al processo
+padre (vedi \secref{sec:sig_job_control}) ed infine ritorna lo stato di uscita
+specificato in \param{status} che può essere raccolto usando la funzione
+\func{wait} (vedi \secref{sec:proc_wait}).
 
 
-\subsection{Le funzioni \texttt{atexit} e \texttt{on\_exit}}
+\subsection{Le funzioni \func{atexit} e \func{on\_exit}}
 \label{sec:proc_atexit}
 
-Come accennato l'uso di \texttt{exit} al posto della \texttt{\_exit} è fatto
-principalmente per permettere una uscita pulita dalle funzioni delle librerie
-standard del C (in particolare per quel che riguarda la chiusura degli
-stream). 
-
-Quando si realizza una libreria da usare in varie applicazioni può essere
-perciò utile evitare di richiedere di chiamare esplicitamente un funzione di
-uscita che esegua tutte le operazioni di pulizia prima di uscire (come quella
-di salvare eventuali dati sospesi). È invece molto meno soggetto ad errori e
-completamente trasparente all'utente poter effettuare una chiamata automatica
-di una funzione che effettui tali operazioni all'uscita dal programma.
-
-A questo scopo lo standard ANSI C prevede la possibilità di registrare un
-certo numero funzioni che verranno eseguite all'uscita dal programma (sia per
-la chiamata ad \textit{exit} che per il ritorno di \texttt{main}). La prima
-funzione che si può utilizzare a tal fine è:
+Un'esigenza comune che si incontra nella programmazione è quella di dover
+effettuare una serie di operazioni di pulizia (ad esempio salvare dei dati,
+ripristinare delle impostazioni, eliminare dei file temporanei, ecc.) prima
+della conclusione di un programma. In genere queste operazioni vengono fatte
+in un'apposita sezione del programma, ma quando si realizza una libreria
+diventa antipatico dover richiedere una chiamata esplicita ad una funzione di
+pulizia al programmatore che la utilizza.
+
+È invece molto meno soggetto ad errori, e completamente trasparente
+all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
+una funzione che effettui tali operazioni all'uscita dal programma. A questo
+scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
+funzioni che verranno eseguite all'uscita dal programma (sia per la chiamata
+ad \func{exit} che per il ritorno di \func{main}). La prima funzione che si
+può utilizzare a tal fine è:
 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
-  Registra la funzione \texttt{function} per essere chiamata all'uscita dal
+  Registra la funzione \param{function} per essere chiamata all'uscita dal
   programma. 
-
-  La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
-  \texttt{errno} non viene settata.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    fallimento, \var{errno} non viene modificata.}
 \end{prototype}
-
-La funzione richiede come argomento l'indirizzo della opportuna da chiamare
-all'uscita che non deve prendere argomenti e non deve ritornare niente. Una
-estensione di \texttt{atexit} è la funzione \texttt{on\_exit} (che la glibc
-include per compatibilità con SunOS e che non è detta sia definita su altri
-sistemi), il cui prototipo è:
+\noindent la funzione richiede come argomento l'indirizzo della opportuna
+funzione di pulizia da chiamare all'uscita, che non deve prendere argomenti e
+non deve ritornare niente (deve essere essere cioè definita come \code{void
+  function(void)}).
+
+Un'estensione di \func{atexit} è la funzione \func{on\_exit}, che le
+\acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
+definita su altri sistemi; il suo prototipo è:
 \begin{prototype}{stdlib.h}
 {void on\_exit(void (*function)(int status, void *arg), void *arg)}
-  Registra la funzione \texttt{function} per essere chiamata all'uscita dal
+  Registra la funzione \param{function} per essere chiamata all'uscita dal
   programma. Tutte le funzioni registrate vengono chiamate in ordine inverso
   rispetto a quello di registrazione.
-
-  La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
-  \texttt{errno} non viene settata.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    fallimento, \var{errno} non viene modificata.}
 \end{prototype}
 
 In questo caso la funzione da chiamare prende due parametri, il primo dei
 quali sarà inizializzato allo stato di uscita con cui è stata chiamata
-\texttt{exit} ed il secondo al puntatore generico specificato come secondo
-argomento nella chiamata di \texttt{on\_exit}.
+\func{exit} ed il secondo al puntatore generico specificato come secondo
+argomento nella chiamata di \func{on\_exit}. Così diventa possibile passare
+dei dati alla funzione di chiusura.
 
-Tutte le funzioni registrate vengono chiamate in ordine inverso rispetto a
-quello di registrazione (ed una stessa funzione registrata più volte sarà
-chiamata più volte); poi vengono chiusi tutti gli stream aperti, infine viene
-chiamata \texttt{\_exit}.
+Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
+ordine inverso rispetto a quello di registrazione (ed una stessa funzione
+registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
+stream aperti, infine verrà chiamata \func{\_exit}.
 
 
 \subsection{Conclusioni}
 \label{sec:proc_term_conclusion}
 
 Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
-in un sistema unix l'unico modo in cui un programma può essere eseguito dal
-kernel è attraverso la chiamata alla system call \texttt{execve} (in genere
-attraveso una delle funzioni \texttt{exec} che vedremo in
-\secref{sec:prochand_exec}).
+in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
+kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
+una delle funzioni della famiglia \func{exec} che vedremo in
+\secref{sec:proc_exec}).
 
 Allo stesso modo l'unico modo in cui un programma può concludere
 volontariamente la sua esecuzione è attraverso una chiamata alla system call
-\texttt{\_exec} sia esplicitamente o che in maniera indiretta attraverso l'uso
-di \texttt{exit} o il ritorno della funzione \texttt{main}.
+\func{\_exit}, o esplicitamente, o in maniera indiretta attraverso l'uso di
+\func{exit} o il ritorno di \func{main}.
 
-Lo schema delle modalità con cui si avvia e conclude normalmente un programma
-è riportato in \nfig.
+Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
+normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}.
 
 \begin{figure}[htb]
   \centering
-  
+  \includegraphics[width=12cm]{img/proc_beginend}
   \caption{Schema dell'avvio e della conclusione di un programma.}
   \label{fig:proc_prog_start_stop}
 \end{figure}
 
 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
-\curfig); torneremo su questo aspetto in \secref{cha:signals}.
+\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
+\capref{cha:signals}.
 
 
 
 \section{I processi e l'uso della memoria}
 \label{sec:proc_memory}
 
-Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed
-uno degli aspetti più complessi di un sistema unix (ed in particolar modo di
-Linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
-memoria viene vista dal punto di vista di un programma in esecuzione in un
-processo.
+Una delle risorse base che ciascun processo ha a disposizione è la memoria, e
+la gestione della memoria è appunto uno degli aspetti più complessi di un
+sistema unix-like. In questa sezione, dopo una breve introduzione ai concetti
+base, esamineremo come la memoria viene vista da parte di un programma in
+esecuzione, e le varie funzioni utilizzabili per la sua gestione.
 
 
 \subsection{I concetti generali}
 \label{sec:proc_mem_gen}
 
 Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
-di basso livello dipendono in maniera diretta dall'architettura
-dell'hardware), ma quello più tipico, usato da unix (e da Linux) è quello di
-assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in
-cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di
-Linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
-kernel 2.4 il limite è stato esteso).
-
-Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non
-corrisponde all'effettiva posizione dei dati nella RAM del computer; in genere
-detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono
-utilizzabili e/o utilizzati).
-
-La memoria virtuale viene divisa in pagine (che ad esempio sono di 4kb su
-macchine a 32 bit e 8kb sulle alpha, valori strettamente connessi all'hardware
-di gestione della memoria) di dimensione fissa, e ciascuna pagina della
-memoria virtuale è associata ad un supporto che può essere una pagina di
-memoria reale o ad un dispositivo di stoccaggio secondario (in genere lo spazio
-disco riservato alla swap, o i file che contengono il codice).
+di basso livello dipendono spesso in maniera diretta dall'architettura
+dell'hardware), ma quello più tipico, usato dai sistemi unix-like come Linux è
+la cosiddetta \textsl{memoria virtuale}\index{memoria virtuale} che consiste
+nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare,
+in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel
+  caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di
+  2Gb, con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite
+  è stato esteso.}
+
+Come accennato in \capref{cha:intro_unix} questo spazio di indirizzi è
+virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
+computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
+indirizzi possibili sono utilizzabili, e quelli usabili non sono
+necessariamente adiacenti).
+
+Per la gestione da parte del kernel la memoria virtuale viene divisa in pagine
+di dimensione fissa (che ad esempio sono di 4kb su macchine a 32 bit e 8kb
+sulle alpha, valori strettamente connessi all'hardware di gestione della
+memoria), e ciascuna pagina della memoria virtuale è associata ad un supporto
+che può essere una pagina di memoria reale o ad un dispositivo di stoccaggio
+secondario (in genere lo spazio disco riservato alla swap, o i file che
+contengono il codice).
 
 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
 diverse pagine di memoria virtuale appartenenti a processi diversi (come
 accade in genere per le pagine che contengono il codice delle librerie
-condivise). Ad esempio il codice della funzione \texttt{printf} starà su una
+condivise). Ad esempio il codice della funzione \func{printf} starà su una
 sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
-virtuale di tutti i processi hanno detta funzione nel loro codice. 
+virtuale di tutti i processi che hanno detta funzione nel loro codice.
 
 La corrispondenza fra le pagine della memoria virtuale e quelle della memoria
 fisica della macchina viene gestita in maniera trasparente dall'hardware di
-gestione della memoria (dalla \textit{Memory Management Unit} del processore),
-ma poiché in genere quest'ultima è solo una piccola frazione della memoria
-virtuale è necessario un meccanismo che permetta di trasferire le pagine
-virtuali che servono dal supporto su cui si trovano in memoria eliminando
-quelle che non servono. Questo meccanismo è detto \textit{paging}, ed è uno
-dei compiti principali del kernel.
+gestione della memoria (la \textit{Memory Management Unit} del processore).
+Poiché in genere la memoria fisica è solo una piccola frazione della memoria
+virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
+servono dal supporto su cui si trovano in memoria, eliminando quelle che non
+servono. Questo meccanismo è detto \textsl{paginazione}\index{paginazione} (o
+\textit{paging}), ed è uno dei compiti principali del kernel.
 
 Quando un processo cerca di accedere ad una pagina che non è nella memoria
-reale avviene quello che viene chiamato un \textit{page fault}, l'hardware di
-gestione della memoria (la MMU del processore) genera una interruzione e passa
+reale, avviene quello che viene chiamato un 
+\textit{page fault}\index{page fault}; 
+l'hardware di gestione della memoria genera un'interruzione e passa
 il controllo al kernel il quale sospende il processo e si incarica di mettere
 in RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
-reperire lo spazio necessario), per poi restituire il controllo al
-processo. 
+reperire lo spazio necessario), per poi restituire il controllo al processo.
 
 Dal punto di vista di un processo questo meccanismo è completamente
-trasparente e tutto avviene come se tutte le pagine fossero sempre disponibili
-in memoria.  L'unica differenza avvertibile è quella dei tempi di esecuzione,
-che passano dai pochi nanosecondi necessari per l'accesso a tempi molto più
-lunghi, dovuti all'intervento del kernel. Normalmente questo è il prezzo da
-pagare per avere un multitasking reale, ed in genere il sistema è molto
-efficiente in questo lavoro; quando però ci siano esigenze specifiche di
-prestazioni è possibile usare delle funzioni che permettono di bloccare il
-meccanismo del paging e mantenere fisse delle pagine in memoria (vedi
-\ref{sec:proc_mem_lock}).
+trasparente, e tutto avviene come se tutte le pagine fossero sempre
+disponibili in memoria.  L'unica differenza avvertibile è quella dei tempi di
+esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM,
+a tempi molto più lunghi, dovuti all'intervento del kernel. 
+
+Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
+in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
+esigenze specifiche di prestazioni è possibile usare delle funzioni che
+permettono di bloccare il meccanismo della paginazione e mantenere fisse delle
+pagine in memoria (vedi \ref{sec:proc_mem_lock}).
 
 
 \subsection{La struttura della memoria di un processo}
@@ -319,53 +319,57 @@ Bench
 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
 commette quando si è manipolato male un puntatore e genera quello che viene
-chiamato un \textit{segmentation fault}, si tenta cioè di leggere e scrivere
-da un indirizzo per il quale non esiste una associazione della pagina virtuale
-ed il kernel risponde al relativo \textit{page fault} mandando un segnale
-\texttt{SIGSEGV} al processo, che normalmente ne causa la terminazione
-immediata.
-
-È pertanto importante capire come viene strutturata la memoria virtuale di un
-processo; essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
-indirizzi virtuali ai quali il processo può accedere. Solitamente un
-programma C viene suddiviso nei seguenti segmenti:
+chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
+scrivere da un indirizzo per il quale non esiste un'associazione della pagina
+virtuale, il kernel risponde al relativo \textit{page fault}\index{page fault}
+mandando un segnale \macro{SIGSEGV} al processo, che normalmente ne causa la
+terminazione immediata.
+
+È pertanto importante capire come viene strutturata \textsl{la memoria
+  virtuale}\index{page fault} di un processo. Essa viene divisa in
+\textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
+processo può accedere.  Solitamente un programma C viene suddiviso nei
+seguenti segmenti:
 
 \begin{enumerate}
-\item Il segmento di testo (\textit{text segment}). Contiene il codice
-  macchina del programma e le costanti statiche. Normalmente viene condiviso
-  così che più processi (anche diversi nel caso di librerie) possano
-  utilizzarlo e viene marcato in sola lettura per evitare sovrascritture
+\item Il segmento di testo o \textit{text segment}. Contiene il codice del
+  programma, delle funzioni di librerie da esso utilizzate, e le costanti.
+  Normalmente viene condiviso fra tutti i processi che eseguono lo stesso
+  programma (e anche da processi che eseguono altri programmi nel caso delle
+  librerie).  Viene marcato in sola lettura per evitare sovrascritture
   accidentali (o maliziose) che ne modifichino le istruzioni.
   
-  Viene allocato da \texttt{exec} all'avvio del programma e resta invariato
+  Viene allocato da \func{exec} all'avvio del programma e resta invariato
   per tutto il tempo dell'esecuzione.
   
-\item Il segmento dei dati (\textit{data segment}). Contiene le variabili
-  globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è
-  diviso in due parti.
+\item Il segmento dei dati o \textit{data segment}. Contiene le variabili
+  globali (cioè quelle definite al di fuori di tutte le funzioni che
+  compongono il programma) e le variabili statiche (cioè quelle dichiarate con
+  l'attributo \ctyp{static}). Di norma è diviso in due parti.
   
   La prima parte è il segmento dei dati inizializzati, che contiene le
-  variabili globali il cui valore è stato assegnato esplicitamente. Ad esempio
+  variabili il cui valore è stato assegnato esplicitamente. Ad esempio
   se si definisce:
-\begin{verbatim}
+  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
     double pi = 3.14;
-\end{verbatim}
+  \end{lstlisting}
   questo valore sarà immagazzinato in questo segmento. La memoria di questo
-  segmento viene preallocato dalla \texttt{exec} e inizializzata ai valori
+  segmento viene preallocata all'avvio del programma e inizializzata ai valori
   specificati.
   
   La seconda parte è il segmento dei dati non inizializzati, che contiene le
-  variabili globali il cui valore è stato non è assegnato esplicitamente. Ad
-  esempio se si definisce:
-\begin{verbatim}
+  variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
+  si definisce:
+  \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
     int vect[100];
-\end{verbatim}
-  questo valore sarà immagazzinato in questo segmento. Anch'esso viene
-  allocato all'avvio, e tutte le variabili vengono inizializzate a
-  zero (ed i puntatori a \texttt{NULL}). 
-  
+  \end{lstlisting}
+  questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
+  allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
+  puntatori a \macro{NULL}).\footnote{si ricordi che questo vale solo per le
+    variabili che vanno nel segmento dati, e non è affatto vero in generale.}
+   
   Storicamente questo segmento viene chiamato BBS (da \textit{block started by
-    symbol}. La sua dimensione è fissa.
+    symbol}). La sua dimensione è fissa.
   
 \item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
   segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
@@ -377,10 +381,13 @@ programma C viene suddiviso nei seguenti segmenti:
 \item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
   programma.  Tutte le volte che si effettua una chiamata ad una funzione è
   qui che viene salvato l'indirizzo di ritorno e le informazioni dello stato
-  del chiamante (tipo il contenuto di alcuni registri della CPU); poi la
-  funzione chiamata alloca qui lo spazio per le sue variabili locali, in
+  del chiamante (tipo il contenuto di alcuni registri della CPU). Poi la
+  funzione chiamata alloca qui lo spazio per le sue variabili locali: in
   questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
-  della funzione lo spazio è automaticamente rilasciato.
+  della funzione lo spazio è automaticamente rilasciato e ``ripulito''. La
+  pulizia in C e C++ viene fatta dal chiamante.\footnote{a meno che non sia
+    stato specificato l'utilizzo di una calling convention diversa da quella
+    standard.}
   
   La dimensione di questo segmento aumenta seguendo la crescita dello stack
   del programma, ma non viene ridotta quando quest'ultimo si restringe.
@@ -388,419 +395,564 @@ programma C viene suddiviso nei seguenti segmenti:
 
 \begin{figure}[htb]
   \centering
-  
-  \caption{Disposizione tipica dei segmenti di memoria di un processo}
+  \includegraphics[width=5cm]{img/memory_layout}
+  \caption{Disposizione tipica dei segmenti di memoria di un processo.}
   \label{fig:proc_mem_layout}
 \end{figure}
 
-Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il
-comando \texttt{size} su un programma se ne può stampare le dimensioni dei
-segmenti di testo e di dati (inizializzati e BSS); il BSS però non è mai
-salvato sul file, in quanto viene inizializzato a zero al caricamento del
-programma.
+Una disposizione tipica di questi segmenti è riportata in
+\figref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
+ne può stampare le dimensioni dei segmenti di testo e di dati (inizializzati e
+BSS); si tenga presente però che il BSS non è mai salvato sul file che
+contiene l'eseguibile, dato che viene sempre inizializzato a zero al
+caricamento del programma.
 
 
 \subsection{Allocazione della memoria per i programmi C}
 \label{sec:proc_mem_alloc}
 
-Il C supporta due tipi di allocazione della memoria, l'allocazione statica è
-quella in cui vanno le variabili globali e le variabili statiche (e viene
-effettuata nel segmento dei dati), lo spazio per queste variabili viene
-allocati all'avvio del programma (come parte delle operazioni svolte da
-\texttt{exec}) e non viene liberato fino alla sua conclusione.
+Il C supporta, a livello di linguaggio, soltanto due modalità di allocazione
+della memoria: l'\textsl{allocazione statica} e l'\textsl{allocazione
+  automatica}.
 
-L'allocazione automatica è quella che avviene per le cosiddette variabili
-automatiche, cioè gli argomenti delle funzioni o le variabili locali. Lo
-spazio per queste variabili viene allocato nello stack quando viene eseguito
-comando di invocazione della funzione e liberato quando si esce dalla
-medesima.
+L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
+globali e le variabili statiche, cioè le variabili il cui valore deve essere
+mantenuto per tutta la durata del programma. Come accennato queste variabili
+vengono allocate nel segmento dei dati all'avvio del programma (come parte
+delle operazioni svolte da \func{exec}) e lo spazio da loro occupato non viene
+liberato fino alla sua conclusione.
 
-Esiste però un terzo tipo di allocazione, che non è prevista dal linguaggio C,
-che è l'allocazione dinamica della memoria, necessaria quando il quantitativo
-di memoria che serve è determinabile solo in corso di esecuzione del
-programma. 
+L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
+una funzione e per le sue variabili locali (le cosiddette \textsl{variabili
+  automatiche}), che esistono solo per la durata della funzione.  Lo spazio
+per queste variabili viene allocato nello stack quando viene eseguita la
+funzione e liberato quando si esce dalla medesima.
+
+Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica della
+  memoria}, che non è prevista direttamente all'interno del linguaggio C, ma
+che è necessaria quando il quantitativo di memoria che serve è determinabile
+solo durante il corso dell'esecuzione del programma.
 
 Il C non consente di usare variabili allocate dinamicamente, non è possibile
 cioè definire in fase di programmazione una variabile le cui dimensioni
-possano essere modificate durante l'esecuzione del programma; però le librerie
-del C forniscono una serie opportuna di funzioni per permettere l'allocazione
-dinamica di spazio in memoria (in genere nello heap, usando la system call
-\texttt{sbrk}), solo che a questo punto detto spazio sarà accessibile solo in
-maniera indiretta attraverso dei puntatori.
+possano essere modificate durante l'esecuzione del programma. Per questo le
+librerie del C forniscono una serie opportuna di funzioni per eseguire
+l'allocazione dinamica di memoria (in genere nello heap). Le variabili il
+cui contenuto è allocato in questo modo non potranno essere usate direttamente
+come le altre, ma l'accesso sarà possibile solo in maniera indiretta,
+attraverso dei puntatori.
 
 
-\subsection{Le funzioni \texttt{malloc}, \texttt{calloc}, \texttt{realloc} e
-  \texttt{free}}  
+\subsection{Le funzioni \func{malloc}, \func{calloc}, \func{realloc} e
+  \func{free}}
 \label{sec:proc_mem_malloc}
 
 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
-quattro, i prototipi sono i seguenti:
-\begin{prototypes}
+quattro: \func{malloc}, \func{calloc}, \func{realloc} e \func{free}, i loro
+prototipi sono i seguenti:
+\begin{functions}
 \headdecl{stdlib.h}
 \funcdecl{void *calloc(size\_t size)}
-  Alloca \texttt{size} bytes nello heap. La memoria viene inizializzata a 0.
+  Alloca \var{size} byte nello heap. La memoria viene inizializzata a 0.
   
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \texttt{NULL} in caso di fallimento, nel qual caso
-  \texttt{errno} viene settata a \texttt{ENOMEM}.
+  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void *malloc(size\_t size)}
-  Alloca \texttt{size} bytes nello heap. La memoria non viene inizializzata.
+  Alloca \var{size} byte nello heap. La memoria non viene inizializzata.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \texttt{NULL} in caso di fallimento, nel qual caso
-  \texttt{errno} viene settata a \texttt{ENOMEM}.
+  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void *realloc(void *ptr, size\_t size)}
-  Cambia la dimensione del blocco allocato all'indirizzo \texttt{ptr}
-  portandola a \texttt{size}.
+  Cambia la dimensione del blocco allocato all'indirizzo \var{ptr}
+  portandola a \var{size}.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \texttt{NULL} in caso di fallimento, nel qual caso
-  \texttt{errno} viene settata a \texttt{ENOMEM}.
+  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void free(void *ptr)}
-  Disalloca lo spazio di memoria puntato da \texttt{ptr}.
+  Disalloca lo spazio di memoria puntato da \var{ptr}.
 
-  La funzione non ritorna nulla.
+  La funzione non ritorna nulla e non riporta errori.
+\end{functions}
+Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre
+allineato correttamente per tutti i tipi di dati; ad esempio sulle macchine a
+32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
+multipli di 8 byte.
 
-\end{prototypes}
-\begin{prototype}{stdlib.h}{void *calloc(size\_t size)}
-  Alloca \texttt{size} bytes nello heap. La memoria viene inizializzata a 0.
-  
-  La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \texttt{NULL} in caso di fallimento, nel qual caso
-  \texttt{errno} viene settata a \texttt{ENOMEM}.
-\end{prototype}
-\begin{prototype}{stdlib.h}{void *malloc(size\_t size)}
-  Alloca \texttt{size} bytes nello heap. La memoria non viene inizializzata.
-
-  La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \texttt{NULL} in caso di fallimento, nel qual caso
-  \texttt{errno} viene settata a \texttt{ENOMEM}.
-\end{prototype}
-\begin{prototype}{stdlib.h}{void free(void *ptr)}
-  Disalloca lo spazio di memoria puntato da \texttt{ptr}.
-
-  La funzione non ritorna nulla.
-\end{prototype}
-\begin{prototype}{stdlib.h}{void *realloc(void *ptr, size\_t size)}
-  Cambia la dimensione del blocco allocato all'indirizzo \texttt{ptr}
-  portandola a \texttt{size}.
-
-  La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \texttt{NULL} in caso di fallimento, nel qual caso
-  \texttt{errno} viene settata a \texttt{ENOMEM}.
-\end{prototype}
-
-Il puntatore che le funzioni di allocazione ritornano è garantito essere
-sempre correttamente allineato per tutti i tipi di dati; ad esempio sulle
-macchine a 32 bit in genere è allineato a multipli di 4 bytes e sulle macchine
-a 64 bit a multipli di 8 bytes. 
-
-In genere su usano le funzioni \texttt{malloc} e \texttt{calloc} per allocare
-dinamicamente la memoria necessaria al programma, siccome i puntatori
+In genere si usano le funzioni \func{malloc} e \func{calloc} per allocare
+dinamicamente la memoria necessaria al programma, e siccome i puntatori
 ritornati sono di tipo generico non è necessario effettuare un cast per
-assegnarli a puntatori al tipo di variabile per la quale si effettua la
-allocazione.
+assegnarli a puntatori al tipo di variabile per la quale si effettua
+l'allocazione.
 
 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
-\texttt{free}\footnote{le glibc provvedono anche una funzione \texttt{cfree}
-  defininita per compatibilità con SunOS, che è deprecata} una volta che non
+\func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
+  definita per compatibilità con SunOS, che è deprecata.} una volta che non
 sia più necessaria. Questa funzione vuole come parametro un puntatore
 restituito da una precedente chiamata a una qualunque delle funzioni di
-allocazione e che non sia già stato liberato da un'altra chiamata a
-\texttt{free}, in caso contrario il comportamento della funzione è indefinito.
-
-La funzione \texttt{realloc} si usa invece per cambiare (in genere aumentare)
-la dimensione di un'area di memoria precedentemente allocata, la funzione
-vuole in ingresso il puntatore restituito dalla precedente chiamata ad una
-\texttt{malloc} (se è passato un valore \texttt{NULL} allora la funzione si
-comporta come \texttt{malloc}\footnote{questo è vero per linux e
+allocazione che non sia già stato liberato da un'altra chiamata a \func{free},
+in caso contrario il comportamento della funzione è indefinito.
+
+La funzione \func{realloc} si usa invece per cambiare (in genere aumentare) la
+dimensione di un'area di memoria precedentemente allocata, la funzione vuole
+in ingresso il puntatore restituito dalla precedente chiamata ad una
+\func{malloc} (se è passato un valore \macro{NULL} allora la funzione si
+comporta come \func{malloc})\footnote{questo è vero per Linux e
   l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
   vecchie implementazioni, inoltre alcune versioni delle librerie del C
-  consentivano di usare \texttt{realloc} anche per un puntatore liberato con
-  \texttt{free} purché non ci fossero state altre chiamate a funzioni di
-  allocazione, questa funzionalità è totalmente deprecata e non è consentita
-  sotto linux}), ad esempio quando si deve far crescere la dimensione di un
-vettore; in questo caso se è disponibile dello spazio adiacente al precedente
-la funzione lo utilzza, altrimenti rialloca altrove un blocco della dimensione
-voluta copiandoci automaticamente il contenuto, lo spazio in più non viene
-inizializzato. 
-
-Il fatto che il blocco di memoria restituito da \texttt{realloc} possa
-camabiare comporta che si deve sempre riassegnare al puntatore passato per il
-ridimensionamento il valore di ritorno della funzione, e che non ci devono
-essere altri puntatori che puntino all'interno di un'area che si vuole
-ridimensionare.
-
-
-Uno degli errori più comuni (specie se si ha a che fare con array di
-puntatori) è infatti quello di chiamare \texttt{free} più di una volta sullo
-stesso puntatore; per evitare questo problema una soluzione di ripiego è
-quella di assegnare sempre a \texttt{NULL} ogni puntatore liberato con
-\texttt{free}, dato che, quando il parametro è un puntatore nullo,
-\texttt{free} non esegue nessuna operazione. 
-
-Linux e le glibc hanno una implementazione delle routine di allocazione che è
+  consentivano di usare \func{realloc} anche per un puntatore liberato con
+  \func{free} purché non ci fossero state nel frattempo altre chiamate a
+  funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
+  consentita sotto Linux.} ad esempio quando si deve far crescere la
+dimensione di un vettore. In questo caso se è disponibile dello spazio
+adiacente al precedente la funzione lo utilizza, altrimenti rialloca altrove
+un blocco della dimensione voluta, copiandoci automaticamente il contenuto; lo
+spazio aggiunto non viene inizializzato.
+
+Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
+da \func{realloc} può non essere un'estensione di quello che gli si è passato
+in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
+\var{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
+ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
+blocco di dati ridimensionato.
+
+Un errore abbastanza frequente (specie se si ha a che fare con array di
+puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
+puntatore; per evitare questo problema una soluzione di ripiego è quella di
+assegnare sempre a \macro{NULL} ogni puntatore liberato con \func{free}, dato
+che, quando il parametro è un puntatore nullo, \func{free} non esegue nessuna
+operazione.
+
+Le \acr{glibc} hanno un'implementazione delle routine di allocazione che è
 controllabile dall'utente attraverso alcune variabili di ambiente, in
 particolare diventa possibile tracciare questo tipo di errori usando la
-variabile \texttt{MALLOC\_CHECK\_} che quando viene settata mette in uso una
-versione meno efficiente delle funzioni, che però è più tollerante nei
-confronti di piccoli errori come quello di chiamate doppie a \texttt{free}; in
-pparticolare se la variabile è posta a zero gli errori vengono ignorati, se è
-posta ad 1 viene stampato un avviso sullo standard error e se 
-
-Il problema più comune e più difficile da tracciare che si incontra con
-l'allocazione della memoria è però quando la memoria non più utilizzata non
-viene opportunamente liberata (quello che in inglese viene chiamato
-\textit{memory-leak}, traducibile come \textsl{perdita di memoria}).
-
-Un caso tipico è quando l'allocazione viene fatta da una subroutine per un uso
-locale, ma la memoria non viene liberata una volta usata; chiamate ripetute
-alla stessa suubroutine causeranno a lungo andare un esaurimento della memoria
-disponibile, con un conseguente crash dell'applicazione che può avvenire in
-qualunque momento senza nessuna relazione con la subroutine che contiene
-l'errore. 
-
-Per questo motivo l'implementazione delle routine di allocazione delle glibc
-mette a disposizione una serie di funzionalità (su cui torneremo in
-\secref{sec:proc_mem_advanced}) che permettono di tracciare le allocazioni e
-le disallocazione, e definisce anche una serie di possibili agganci che
-permettono di sostituire alle funzioni di libreria una propria versione (che
-può essere più o meno specializzata per il debugging).
-
-\subsection{La funzione \texttt{alloca}}  
+variabile \macro{MALLOC\_CHECK\_} che quando viene definita mette in uso una
+versione meno efficiente delle funzioni suddette, che però è più tollerante
+nei confronti di piccoli errori come quello di chiamate doppie a \func{free}.
+In particolare:
+\begin{itemize}
+\item se la variabile è posta a zero gli errori vengono ignorati.
+\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
+  (vedi \secref{sec:file_std_stream}).
+\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
+  l'immediata conclusione del programma.
+\end{itemize}
+
+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}.
+
+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
+memoria resta così allocata fino alla terminazione del processo.  Chiamate
+ripetute alla stessa subroutine continueranno ad effettuare altre allocazioni,
+causando a lungo andare un esaurimento della memoria disponibile (e la
+probabile impossibilità di proseguire l'esecuzione del programma).
+
+Il problema è che l'esaurimento della memoria può avvenire in qualunque
+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}.
+
+In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
+programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
+ridimensionato attraverso l'uso accurato di appositi oggetti come gli
+\textit{smartpointers}.  Questo però va a scapito delle performance
+dell'applicazione in esecuzione.
+
+In altri linguaggi come il java e recentemente il C\# il problema non si pone
+nemmeno perché la gestione della memoria viene fatta totalmente in maniera
+automatica, ovvero il programmatore non deve minimamente preoccuparsi di
+liberare la memoria allocata precedentemente quando non serve più, poiché il
+framework gestisce automaticamente la cosiddetta \textit{garbage collection}.
+In tal caso, attraverso meccanismi simili a quelli del \textit{reference
+  counting}, quando una zona di memoria precedentemente allocata non è più
+riferita da nessuna parte del codice in esecuzione, può essere deallocata
+automaticamente in qualunque momento dall'infrastruttura.
+
+Anche questo va a scapito delle performance dell'applicazione in esecuzione
+(inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
+eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
+la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
+di per sé delle performance più scadenti rispetto alle stesse applicazioni
+compilate direttamente).  Questo comporta però il problema della non
+predicibilità del momento in cui viene deallocata la memoria precedentemente
+allocata da un oggetto.
+
+Per limitare l'impatto di questi problemi, e semplificare la ricerca di
+eventuali errori, l'implementazione delle routine di allocazione delle
+\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
+tracciare le allocazioni e le disallocazione, e definisce anche una serie di
+possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
+funzioni di libreria una propria versione (che può essere più o meno
+specializzata per il debugging). Esistono varie librerie che forniscono dei
+sostituti opportuni delle routine di allocazione in grado, senza neanche
+ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
+  \href{http://dmalloc.com/}{http://dmalloc.com/} di Gray Watson ed
+  \textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche
+molto complesse riguardo l'allocazione della memoria.
+
+
+
+\subsection{La funzione \func{alloca}}  
 \label{sec:proc_mem_alloca}
 
-Una alternativa possibile all'uso di \texttt{malloc}, che non soffre del tipo
-di problemi di memomry leak descritti in precedenza è la funzione
-\texttt{alloca} che invece che allocare la memoria nello heap usa lo il
-segmento di stack della funzione corrente. La sintassi è identica:
+Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
+problemi di \textit{memory leak} descritti in precedenza, è la funzione
+\func{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 \texttt{size} bytes nel segmento di stack della funzione chiamante.
+  Alloca \var{size} byte nel segmento di stack della funzione chiamante.
   La memoria non viene inizializzata.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \texttt{NULL} in caso di fallimento, nel qual caso
-  \texttt{errno} viene settata a \texttt{ENOMEM}.
+  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  \var{errno} assumerà il valore \macro{ENOMEM}.
 \end{prototype}
-ma in questo caso non è più necessario liberare la memoria in quanto questa
-viene rilasciata automaticamente al ritorno della funzione.
-
-Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
-problemi di memory leak non essendo più necessaria la deallocazione esplicita;
-una delle ragioni principali per usarla è però che funziona anche quando si
-usa \texttt{longjump} per uscire con un salto non locale da una funzione (vedi
-\secref{sec:proc_longjmp}), 
-
-Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
-sprecato spazio, infatti non è necessario gestire un pool di memoria da
-riservare e si evitano anche problemi di frammentazione.
-
-Gli svantaggi sono che la funzione non è disponibile su tutti gli unix quando
-non è possibile aumentare le dimensioni dello stack una volta chiamata una
-funzione e quindi l'uso limita la portabilità dei programmi, inoltre se si
-cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un
-segnale di \textit{segmentation violation} analogo a quello che si avrebbe da
-una ricorsione infinita.
-
-
-\subsection{Le funzioni \texttt{brk} e \texttt{sbrk}}  
+\noindent ma in questo caso non è più necessario liberare la memoria (e 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
+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}).
+
+Un altro vantaggio è che in Linux la funzione è molto più veloce di
+\func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
+pool di memoria da riservare e si evitano così anche i problemi di
+frammentazione di quest'ultimo, che comportano inefficienze sia
+nell'allocazione della memoria che nell'esecuzione dell'allocazione.
+
+Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
+non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
+suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
+non può essere usata nella lista degli argomenti di una funzione, perché lo
+spazio verrebbe allocato nel mezzo degli stessi.
+
+% Questo è riportato solo dal manuale delle glibc, nelle pagine di manuale non c'è 
+% traccia di tutto ciò
+%
+%Inoltre se si
+%cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un
+%segnale di \textit{segment violation} analogo a quello che si avrebbe da una
+%ricorsione infinita.
+
+Inoltre non è chiaramente possibile usare \func{alloca} per allocare memoria
+che deve poi essere usata anche al di fuori della funzione in cui essa viene
+chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
+libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
+Questo è lo stesso problema che si può avere con le variabili automatiche, su
+cui torneremo in \secref{sec:proc_auto_var}.
+
+
+\subsection{Le funzioni \func{brk} e \func{sbrk}}  
 \label{sec:proc_mem_sbrk}
 
 L'uso di queste funzioni è necessario solo quando si voglia accedere alle
-analoghe system call a cui fanno da interfaccia (ad esempio per implementare
-una propria versione di \texttt{malloc}. Le  funzione sono:
-\begin{prototype}{unistd.h}{int *brk(void end\_data\_segment)}
+analoghe system call a cui fanno da interfaccia. I loro prototipi sono:
+\begin{functions}
+  \headdecl{unistd.h}
+  \funcdecl{int brk(void *end\_data\_segment)}
   Sposta la fine del segmento dei dati all'indirizzo specificato da
-  \texttt{end\_data\_segment}.
+  \var{end\_data\_segment}.
   
-  La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
-  nel qual caso \texttt{errno} viene settata a \texttt{ENOMEM}.
-\end{prototype}
-\begin{prototype}{unistd.h}{int *sbrk(ptrdiff\_t increment)}
-  Incrementa lo spazio dati di un programma di \texttt{increment}. Un valore
-  zero restituisce l'attuale posizione della fine del segmento dati.
+  La funzione restituisce 0 in caso di successo e -1 in caso di
+    fallimento, nel qual caso \var{errno} assumerà il valore \macro{ENOMEM}.
+
+  \funcdecl{void *sbrk(ptrdiff\_t increment)} Incrementa lo spazio dati di un
+  programma di \var{increment}. Un valore zero restituisce l'attuale posizione
+  della fine del segmento dati.
   
-  La funzione restituisce il puntatore all'inzio della nuova zona di memoria
-  allocata in caso di successo e \texttt{NULL} in caso di fallimento, nel qual
-  caso \texttt{errno} viene settata a \texttt{ENOMEM}.
-\end{prototype}
+  La funzione restituisce il puntatore all'inizio della nuova zona di memoria
+  allocata in caso di successo e \macro{NULL} in caso di fallimento, nel qual
+  caso \macro{errno} assumerà il valore \macro{ENOMEM}.
+\end{functions}
+\noindent in genere si usa \func{sbrk} con un valore zero per ottenere
+l'attuale posizione della fine del segmento dati.
 
 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
-per i programmi normali è opportuno usare le funzioni di allocazione standard
-descritte in precedenza, che sono costruite su di esse.  In genere si usa
-\texttt{sbrk} con un valore zero per ottenere l'attuale posizione della fine
-del segmento dati. 
+per i programmi normali è sempre opportuno usare le funzioni di allocazione
+standard descritte in precedenza, che sono costruite su di esse.  L'uso di
+queste funzione è ristretto alle specifiche necessità di chi debba
+implementare una sua versione delle routine di allocazione.  
 
 
 % \subsection{La personalizzazione delle funzioni di allocazione} 
 % \label{sec:proc_mem_malloc_custom}
 
 
-\subsection{Il controllo della memoria virtuale}  
-\label{sec:proc_mem_mlock}
+\subsection{Il controllo della memoria virtuale\index{memoria virtuale}}  
+\label{sec:proc_mem_lock}
 
-Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria in
-maniera trasparente ai processi, decidendo quando rimuovere pagine dalla
-memoria per metterle nello swap sulla base dell'utilizzo corrente da parte dei
-vari processi. 
+Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria
+virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
+dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
+parte dei vari processi.
 
-Nell'uso comune un processo non deve preoccuparsi di tutto ciò in quanto il
-meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
-le pagine che gli occorrono; esistono però esigenze particolari in cui non si
-vuole che il meccanismo dello \textit{swapping}, in generale i motivi per cui
-si possono avere queste necessità sono sostanzialmente due:
+Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
+meccanismo della paginazione\index{paginazione} riporta in RAM, ed in maniera
+trasparente, tutte le pagine che gli occorrono; esistono però esigenze
+particolari in cui non si vuole che questo meccanismo si attivi. In generale i
+motivi per cui si possono avere di queste necessità sono due:
 \begin{itemize}
-\item La velocità. Il processo della paginazione è trasparente solo se il
-  programma in esecuzione se non è sensibile al tempo che occorre a riportare
-  la pagina in memoria; per questo motivi processi critici che hanno esigenze
-  di tempo reale o tolleranze critiche nella risposte (ad esempio processi che
-  trattano campionamenti sonori) possono non essere in grado di sopportare
-  le variazioni della velocità di accesso dovuta alla paginazione.
-
+\item \textsl{La velocità}. Il processo della paginazione è trasparente solo
+  se il programma in esecuzione non è sensibile al tempo che occorre a
+  riportare la pagina in memoria; per questo motivo processi critici che hanno
+  esigenze di tempo reale o tolleranze critiche nelle risposte (ad esempio
+  processi che trattano campionamenti sonori) possono non essere in grado di
+  sopportare le variazioni della velocità di accesso dovuta alla paginazione.
+  
   In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
   allocazione delle pagine le esigenze specifiche del suo programma e decidere
   quali pagine di memoria è opportuno che restino in memoria per un aumento
   delle prestazioni. In genere queste sono esigenze particolari e richiedono
-  anche un aumento delle priorità in esecuzione (vedi \secref{sec:xxx_xxx}).
+  anche un aumento delle priorità in esecuzione del processo (vedi
+  \secref{sec:proc_real_time}).
   
-\item La sicurezza. Se si tengono password o chiavi in memoria queste possono
-  essere portate su disco dal meccanismo della paginazione, questo rende più
-  lungo il periodo di tempo in cui i segreti sono presenti in chiaro, e
-  complessa la loro cancellazione (in genere è possibile cancellare della ram
-  ma altrettanto non vale per il disco su cui la pagina contenente i segreti
-  può essere stata salvata). Per questo motivo programmi di crittografia
-  richiedono il blocco di alcune pagine di memoria.
+\item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
+  in memoria queste possono essere portate su disco dal meccanismo della
+  paginazione. Questo rende più lungo il periodo di tempo in cui detti segreti
+  sono presenti in chiaro e più complessa la loro cancellazione (un processo
+  può cancellare la memoria su cui scrive le sue variabili, ma non può toccare
+  lo spazio disco su cui una pagina di memoria può essere stata salvata). Per
+  questo motivo di solito i programmi di crittografia richiedono il blocco di
+  alcune pagine di memoria.
 \end{itemize}
 
-\section{Il controllo di flusso non locale}
-\label{sec:proc_longjmp}
+Il meccanismo che previene la paginazione di parte della memoria virtuale di
+un processo è chiamato \textit{memory locking} (o \textsl{blocco della
+  memoria}). Il blocco è sempre associato alle pagine della memoria virtuale
+del processo, e non al segmento reale di RAM su cui essa viene mantenuta.
+
+La regola è che se un segmento di RAM fa da supporto ad almeno una pagina
+bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
+non si accumulano, se si blocca due volte la stessa pagina non è necessario
+sbloccarla due volte, una pagina o è bloccata oppure no.
+
+Il \textit{memory lock} persiste fintanto che il processo che detiene la
+memoria bloccata non la sblocca. Chiaramente la terminazione del processo
+comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
+tutti i suoi \textit{memory lock}.
+
+I \textit{memory lock} non sono ereditati dai processi figli.\footnote{ma
+  siccome Linux usa il \textit{copy on write}\index{copy on write} (vedi
+  \secref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti
+  sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non
+  scrive su un segmento, può usufruire del memory lock del padre.}  Siccome la
+presenza di un \textit{memory lock} riduce la memoria disponibile al sistema,
+con un impatto su tutti gli altri processi, solo l'amministratore ha la
+capacità di bloccare una pagina. Ogni processo può però sbloccare le pagine
+relative alla propria memoria.
+
+Il sistema pone dei limiti all'ammontare di memoria di un processo che può
+essere bloccata e al totale di memoria fisica che può dedicare a questo, lo
+standard POSIX.1 richiede che sia definita in \file{unistd.h} la costante
+\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
+\textit{memory locking} e la costante \macro{PAGESIZE} in \file{limits.h} per
+indicare la dimensione di una pagina in byte.
+
+Le funzioni per bloccare e sbloccare singole sezioni di memoria sono
+\func{mlock} e \func{munlock}; i loro prototipi sono:
+\begin{functions}
+  \headdecl{sys/mman.h} 
+
+  \funcdecl{int mlock(const void *addr, size\_t len)}
+  Blocca la paginazione per l'intervallo di memoria da \var{addr} per
+  \var{len} byte. Tutte le pagine che contengono una parte dell'intervallo
+  sono mantenute in RAM per tutta la durata del blocco.
+
+  \funcdecl{int munlock(const void *addr, size\_t len)}
+  Sblocca l'intervallo di memoria da \var{addr} per \var{len} byte.  
 
-Il controllo del flusso di un programma in genere viene effettuato con le
-varie istruzioni del linguaggio C, la più bistrattata delle quali è il
-\texttt{goto} ampiamente deprecato in favore di costrutti più puliti; esiste
-però un caso in l'uso di questa istruzione porta all'implementazione più
-efficiente, quello dell'uscita in caso di errore.
+  
+  \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in
+    caso di errore, nel qual caso \var{errno} assumerà uno dei
+    valori seguenti:
+  \begin{errlist}
+  \item[\macro{ENOMEM}] alcuni indirizzi dell'intervallo specificato non
+    corrispondono allo spazio di indirizzi del processo o si è ecceduto
+    il numero massimo consentito di pagine bloccate.
+  \item[\macro{EINVAL}] \var{len} non è un valore positivo.
+  \end{errlist}
+  e, per \func{mlock}, anche \macro{EPERM} quando il processo non ha i
+  privilegi richiesti per l'operazione.}
+\end{functions}
+
+Altre due funzioni, \func{mlockall} e \func{munlockall}, consentono di
+bloccare genericamente lo spazio di indirizzi di un processo.  I prototipi di
+queste funzioni sono:
+
+\begin{functions}
+  \headdecl{sys/mman.h} 
+
+  \funcdecl{int mlockall(int flags)}
+  Blocca la paginazione per lo spazio di indirizzi del processo corrente. 
+  
+  \funcdecl{int munlockall(void)}
+  Sblocca la paginazione per lo spazio di indirizzi del processo corrente. 
+  
+  \bodydesc{Codici di ritorno ed errori sono gli stessi di \func{mlock}
+    e \func{munlock}.}
+\end{functions}
+
+Il parametro \var{flags} di \func{mlockall} permette di controllarne il
+comportamento; esso può essere specificato come l'OR aritmetico delle due
+costanti: 
+\begin{basedescript}{\desclabelwidth{2.5cm}}
+\item[\macro{MCL\_CURRENT}] blocca tutte le pagine correntemente mappate nello
+  spazio di indirizzi del processo.
+\item[\macro{MCL\_FUTURE}] blocca tutte le pagine che saranno mappate nello
+  spazio di indirizzi del processo.
+\end{basedescript}
+
+Con \func{mlockall} si può bloccare tutte le pagine mappate nello spazio di
+indirizzi del processo, sia che comprendano il segmento di testo, di dati, lo
+stack, lo heap e pure le funzioni di libreria chiamate, i file mappati in
+memoria, i dati del kernel mappati in user space, la memoria condivisa.  L'uso
+dei flag permette di selezionare con maggior finezza le pagine da bloccare, ad
+esempio limitandosi a tutte le pagine allocate a partire da un certo momento.
+
+In ogni caso un processo real-time che deve entrare in una sezione critica
+deve provvedere a riservare memoria sufficiente prima dell'ingresso, per
+scongiurare in partenza un eventuale page fault\index{page fault} causato dal
+meccanismo di \textit{copy on write}\index{copy on write}.  Infatti se nella
+sezione critica si va ad utilizzare memoria che non è ancora stata riportata
+in RAM si potrebbe avere un page fault durante l'esecuzione della stessa, con
+conseguente rallentamento (probabilmente inaccettabile) dei tempi di
+esecuzione.
+
+In genere si ovvia a questa problematica chiamando una funzione che ha
+allocato una quantità sufficientemente ampia di variabili automatiche, in modo
+che esse vengano mappate in RAM dallo stack, dopo di che, per essere sicuri
+che esse siano state effettivamente portate in memoria, ci si scrive sopra.
 
-Il C però non consente di effettuare un salto ad una label definita in
-un'altra funzione, per cui se  l'errore avviene in funzioni profondamente
-annidate
 
 
-\section{La gestione di parametri e opzioni}
+\section{Parametri, opzioni ed ambiente di un processo}
 \label{sec:proc_options}
 
-Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando
-al singolo programma quando viene lanciato è effettuato attraverso le
-variabili \texttt{argc}, \texttt{argv} che vengono passate al programma
-come argomenti della funzione principale.
+Tutti i programmi hanno la possibilità di ricevere parametri e opzioni quando
+vengono lanciati. Il passaggio dei parametri è effettuato attraverso gli
+argomenti \var{argc} e \var{argv} della funzione \func{main}, che vengono
+passati al programma dalla shell (o dal processo che esegue la \func{exec},
+secondo le modalità che vedremo in \secref{sec:proc_exec}) quando questo viene
+messo in esecuzione. 
+
+Oltre al passaggio dei parametri, un'altra modalità che permette di passare
+delle informazioni che modifichino il comportamento di un programma è quello
+dell'uso del cosiddetto \textit{environment} (cioè l'uso delle
+\textsl{variabili di ambiente}). In questa sezione esamineremo le funzioni che
+permettono di gestire parametri ed opzioni, e quelle che consentono di
+manipolare ed utilizzare le variabili di ambiente.
+
 
 \subsection{Il formato dei parametri}
 \label{sec:proc_par_format}
 In genere passaggio dei parametri al programma viene effettuato dalla shell,
 che si incarica di leggere la linea di comando e di effettuarne la scansione
 (il cosiddetto \textit{parsing}) per individuare le parole che la compongono,
-ciascuna delle quali viene considerata un parametro; di default per
-individuare le parole viene usato come separatore lo spazio (comportamento
-modificabile attraverso il settaggio della variabile di ambiente IFS).
+ciascuna delle quali viene considerata un parametro. Di norma per individuare
+le parole viene usato come carattere di separazione lo spazio o il tabulatore,
+ma il comportamento è modificabile attraverso l'impostazione della variabile
+di ambiente \cmd{IFS}.
 
-Nella scansione viene costruito il vettore di puntatori \texttt{argv} inserendo
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=11cm]{img/argv_argc}
+  \caption{Esempio dei valori di \var{argv} e \var{argc} generati nella 
+    scansione di una riga di comando.}
+  \label{fig:proc_argv_argc}
+\end{figure}
+
+Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo
 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
-variabile \texttt{argc} viene inizializzata al numero di parametri trovati, in
-questo modo il primo parametro è sempre il nome del programma (vedi \nfig).
+variabile \var{argc} viene inizializzata al numero di parametri trovati, in
+questo modo il primo parametro è sempre il nome del programma; un esempio di
+questo meccanismo è mostrato in \figref{fig:proc_argv_argc}.
+
 
 \subsection{La gestione delle opzioni}
 \label{sec:proc_opt_handling}
 
-In generale un programma unix riceve da linea di comando sia i parametri che
+In generale un programma Unix riceve da linea di comando sia gli argomenti che
 le opzioni, queste ultime sono standardizzate per essere riconosciute come
-tali: un elemento di \texttt{argv} che inizia con \texttt{-} e che non sia un
-singolo \texttt{-} o \texttt{--} viene considerato un'opzione.  In in genere
-le opzioni sono costituite da una lettera preceduta dal meno e possono avere o
-no un parametro associato; un comando tipico può essere cioè qualcosa del
-tipo:
-\begin{verbatim}
-touch -r riferimento.txt -m questofile.txt
-\end{verbatim}
-ed in questo caso le opzioni sono \texttt{m} ed \texttt{r}.
-
-Per gestire le opzioni all'interno dei parametri passati in \texttt{argv} le
-librerie standard del C forniscono la funzione \texttt{getopt} (accessibile
-includendo \texttt{unistd.h}), che ha il prototipo:
-\begin{verbatim}
-int getopt(int argc, char * const argv[], const char * optstring);
-\end{verbatim}
-
-Questa funzione prende come argomenti le due variabili \texttt{argc} e
-\texttt{argv} ed una stringa che indica quali sono le opzioni valide; la
-funzione effettua la scansione della lista dei parametri ricercando ogni
-stringa che comincia con \texttt{-} e ritorna ogni volta che trova una opzione
+tali: un elemento di \var{argv} che inizia con il carattere \texttt{'-'} e che
+non sia un singolo \texttt{'-'} o un \texttt{'--'} viene considerato
+un'opzione.  In genere le opzioni sono costituite da una lettera singola
+(preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
+associato; un comando tipico può essere quello mostrato in
+\figref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
+e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
+argomento del programma, non un parametro di \cmd{-m}).
+
+Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
+\var{argv} le librerie standard del C forniscono la funzione \func{getopt}
+che ha il seguente prototipo:
+\begin{prototype}{unistd.h}
+{int getopt(int argc, char *const argv[], const char *optstring)}
+Esegue il parsing degli argomenti passati da linea di comando
+riconoscendo le possibili opzioni segnalate con \var{optstring}.
+
+\bodydesc{Ritorna il carattere che segue l'opzione, \cmd{':'} se manca un
+  parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e -1 se non
+  esistono altre opzioni.}
+\end{prototype}
+
+Questa funzione prende come argomenti le due variabili \var{argc} e \var{argv}
+passate a \func{main} ed una stringa che indica quali sono le opzioni valide;
+la funzione effettua la scansione della lista degli argomenti ricercando ogni
+stringa che comincia con \cmd{-} e ritorna ogni volta che trova un'opzione
 valida.
 
-La stringa \texttt{optstring} indica quali sono le opzioni riconosciute ed è
+La stringa \var{optstring} indica quali sono le opzioni riconosciute ed è
 costituita da tutti i caratteri usati per identificare le singole opzioni, se
 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
-due punti \texttt{:} nel caso appena accennato ad esempio la stringa di
-opzioni sarebbe \texttt{"r:m"}.
+due punti \texttt{':'}; nel caso di \figref{fig:proc_argv_argc} ad esempio la
+stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
+
+La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
+funzione all'interno di un ciclo, fintanto che essa non ritorna il valore -1
+che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
+dichiarata in \var{optstring} viene ritornato il carattere \texttt{'?'}
+mentre se un opzione che lo richiede non è seguita da un parametro viene
+ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
+\texttt{'--'} la scansione viene considerata conclusa, anche se vi sono altri
+elementi di \var{argv} che cominciano con il carattere \texttt{'-'}.
 
-La modalità di uso è pertanto quella di chiamare più volte la funzione
-all'interno di un ciclo di while fintanto che essa non ritorna il valore
-\texttt{-1} che indica che non ci sono più opzioni. Nel caso si incontri
-un'opzione non dichiarata in \texttt{optstring} viene ritornato un \texttt{?}
-mentre se l'opzione non è seguita da un parametro viene ritornato un
-\texttt{:} infine se viene incontrato il valore \texttt{--} la scansione viene
-considerata conclusa.
-
-Quando la funzione trova un'opzione essa ritorna il valore numerico del
-carattere, in questo modo si possono prendere le azioni relative usando un
-case; la funzione inizializza inoltre alcune variabili globali:
-\begin{itemize}
-\item \texttt{char * optarg} contiene il puntatore alla stringa argomento
-  dell'opzione.
-\item \texttt{int optind} alla fine della scansione restituisce l'indice del
-  primo argomento che non è un'opzione.
-\item \texttt{int opterr} previene, se posto a zero, la stampa di un messaggio
-  di errore in caso di riconoscimento di opzioni non definite.
-\item \texttt{int optopt} contiene il carattere dell'opzione non riconosciuta.
-\end{itemize}
-
-In \nfig\ è mostrato un programma di esempio, 
-
-\begin{figure}[htbp]
+\begin{figure}[htb]
   \footnotesize
     \begin{lstlisting}{}
     opterr = 0;  /* don't want writing to stderr */
-    while ( (i = getopt(argc, argv, "o:a:i:hve")) != -1) {
+    while ( (i = getopt(argc, argv, "hp:c:e:")) != -1) {
         switch (i) {
-        case 'i':   /* input file */
-            in_file=open(optarg,O_RDONLY);
-            if (in_file<0) {
-                perror("Cannot open input file");
-                exit(1);
-            }
-            break;
-        case 'o':   /* output file (overwrite) */
-            out_file=open(optarg,O_WRONLY|O_CREAT);
-            if (out_file<0) {
-                perror("Cannot open output file");
-                exit(1);
-            }
-            break;
+        /* 
+         * Handling options 
+         */ 
+        case 'h':   /* help option */
+            printf("Wrong -h option use\n");
+            usage();
+            return -1;
             break;
-        case 'a':   /* output file (append) */
-            out_file=open(optarg,O_WRONLY|O_CREAT|O_APPEND);
+        case 'c':   /* take wait time for childen */
+            wait_child = strtol(optarg, NULL, 10);    /* convert input */
             break;
-        case 'h':   /* print help usage */
-            usage();
+        case 'p':   /* take wait time for childen */
+            wait_parent = strtol(optarg, NULL, 10);   /* convert input */
             break;
-        case 'v':   /* set verbose mode */
-            debug("Option -v active\n");
-            verbose=1;
+        case 'e':   /* take wait before parent exit */
+            wait_end = strtol(optarg, NULL, 10);      /* convert input */
             break;
         case '?':   /* unrecognized options */
             printf("Unrecognized options -%c\n",optopt);
             usage();
         default:    /* should not reached */
-            debug("default option\n");
             usage();
         }
     }
@@ -810,15 +962,602 @@ In \nfig\ 
   \label{fig:proc_options_code}
 \end{figure}
 
+Quando la funzione trova un'opzione essa ritorna il valore numerico del
+carattere, in questo modo si possono eseguire azioni specifiche usando uno
+\code{switch}; \func{getopt} inoltre inizializza alcune variabili globali:
+\begin{itemize*}
+\item \var{char *optarg} contiene il puntatore alla stringa parametro
+  dell'opzione.
+\item \var{int optind} alla fine della scansione restituisce l'indice del
+  primo elemento di \var{argv} che non è un'opzione.
+\item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
+  di errore in caso di riconoscimento di opzioni non definite.
+\item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
+\end{itemize*}
+
+In \figref{fig:proc_options_code} è mostrata la sezione del programma
+\file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
+sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
+comando. 
+
+Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
+messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
+la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
+possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
+opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
+(il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
+relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
+\texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind} l'indice
+in \var{argv[]} del primo degli argomenti rimanenti nella linea di comando.
+
+Normalmente \func{getopt} compie una permutazione degli elementi di \var{argv}
+cosicché alla fine della scansione gli elementi che non sono opzioni sono
+spostati in coda al vettore. Oltre a questa esistono altre due modalità di
+gestire gli elementi di \var{argv}; se \var{optstring} inizia con il carattere
+\texttt{'+'} (o è impostata la variabile di ambiente \macro{POSIXLY\_CORRECT})
+la scansione viene fermata non appena si incontra un elemento che non è
+un'opzione. L'ultima modalità, usata quando un programma può gestire la
+mescolanza fra opzioni e argomenti, ma se li aspetta in un ordine definito, si
+attiva quando \var{optstring} inizia con il carattere \texttt{'-'}. In questo
+caso ogni elemento che non è un'opzione viene considerato comunque un'opzione
+e associato ad un valore di ritorno pari ad 1, questo permette di identificare
+gli elementi che non sono opzioni, ma non effettua il riordinamento del
+vettore \var{argv}.
+
+
 \subsection{Opzioni in formato esteso}
 \label{sec:proc_opt_extended}
 
 Un'estensione di questo schema è costituito dalle cosiddette
-\textit{long-options} espresse nella forma \texttt{--option=parameter}, anche
-la gestione di queste ultime è stata standardizzata attraverso l'uso di una
-versione estesa di \texttt{getopt}.
+\textit{long-options} espresse nella forma \cmd{--option=parameter}, anche la
+gestione di queste ultime è stata standardizzata attraverso l'uso di una
+versione estesa di \func{getopt}.
+
+(NdA: da finire).
 
 
 \subsection{Le variabili di ambiente}
-\label{sec:proc_env_var}
+\label{sec:proc_environ}
+
+Oltre agli argomenti passati a linea di comando ogni processo riceve dal
+sistema un \textsl{ambiente}, nella forma di una lista di variabili (detta
+\textit{environment list}) messa a disposizione dal processo, e costruita
+nella chiamata alla funzione \func{exec} quando questo viene lanciato.
+
+Come per la lista dei parametri anche questa lista è un array di puntatori a
+caratteri, ciascuno dei quali punta ad una stringa, terminata da un
+\macro{NULL}. A differenza di \var{argv[]} in questo caso non si ha una
+lunghezza dell'array data da un equivalente di \var{argc}, ma la lista è
+terminata da un puntatore nullo.
+
+L'indirizzo della lista delle variabili di ambiente è passato attraverso la
+variabile globale \var{environ}, a cui si può accedere attraverso una semplice
+dichiarazione del tipo:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+extern char ** environ;
+\end{lstlisting}
+un esempio della struttura di questa lista, contenente alcune delle variabili
+più comuni che normalmente sono definite dal sistema, è riportato in
+\figref{fig:proc_envirno_list}.
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=11cm]{img/environ_var}
+  \caption{Esempio di lista delle variabili di ambiente.}
+  \label{fig:proc_envirno_list}
+\end{figure}
+
+Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
+\textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
+in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
+da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
+usare nomi espressi in caratteri maiuscoli.
+
+Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
+riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
+costituiscono un modo comodo per definire un comportamento specifico senza
+dover ricorrere all'uso di opzioni a linea di comando o di file di
+configurazione. 
+
+La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
+la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e
+alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per
+i dettagli si veda \secref{sec:sess_login}). In genere è cura
+dell'amministratore definire le opportune variabili di ambiente in uno script
+di avvio. Alcune servono poi come riferimento generico per molti programmi
+(come \var{EDITOR} che indica l'editor preferito da invocare in caso di
+necessità).
+
+Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
+comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta
+tutte e ne definisce anche altre: per una lista più completa si può
+controllare \cmd{man environ}.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|c|c|c|p{7cm}|}
+    \hline
+    \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3} 
+    & \textbf{Linux} & \textbf{Descrizione} \\
+    \hline
+    \hline
+    \macro{USER} & $\bullet$ & $\bullet$ & $\bullet$ & Nome utente\\
+    \macro{LOGNAME} & $\bullet$ & $\bullet$ & $\bullet$ & Nome di login\\
+    \macro{HOME} & $\bullet$ & $\bullet$ & $\bullet$ & 
+    Directory base dell'utente\\
+    \macro{LANG} & $\bullet$ & $\bullet$ & $\bullet$ & Localizzazione\\
+    \macro{PATH} & $\bullet$ & $\bullet$ & $\bullet$ & Elenco delle directory
+    dei programmi\\
+    \macro{PWD} & $\bullet$ & $\bullet$ & $\bullet$ & Directory corrente\\
+    \macro{SHELL} & $\bullet$ & $\bullet$ & $\bullet$ & Shell in uso\\
+    \macro{TERM} & $\bullet$ & $\bullet$ & $\bullet$ & Tipo di terminale\\
+    \macro{PAGER} & $\bullet$ & $\bullet$ & $\bullet$ & Programma per vedere i
+    testi\\
+    \macro{EDITOR} & $\bullet$ & $\bullet$ & $\bullet$ & Editor preferito\\
+    \macro{BROWSER} & $\bullet$ & $\bullet$ & $\bullet$ & Browser preferito\\
+    \hline
+  \end{tabular}
+  \caption{Variabili di ambiente più comuni definite da vari standard.}
+  \label{tab:proc_env_var}
+\end{table}
+
+Lo standard ANSI C prevede l'esistenza di un ambiente, pur non entrando nelle
+specifiche di come sono strutturati i contenuti, e definisce la funzione
+\func{getenv} che permette di ottenere i valori delle variabili di ambiente,
+il cui prototipo è:
+\begin{prototype}{stdlib.h}{char *getenv(const char *name)}
+  Esamina l'ambiente del processo cercando una stringa che corrisponda a
+  quella specificata da \param{name}. 
+  
+  \bodydesc{La funzione ritorna \macro{NULL} se non trova nulla, o il
+    puntatore alla stringa che corrisponde (di solito nella forma
+    \cmd{NOME=valore}).}
+\end{prototype}
+
+Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
+C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
+utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
+delle funzioni previste nei vari standard e disponibili in Linux è riportato
+in \tabref{tab:proc_env_func}.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|c|c|c|c|c|c|}
+    \hline
+    \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} & 
+    \textbf{SVr4} & \textbf{BSD} & \textbf{Linux} \\
+    \hline
+    \hline
+    \func{getenv} & $\bullet$ &  $\bullet$ & $\bullet$ & 
+      $\bullet$ & $\bullet$ & $\bullet$ \\
+    \func{setenv} &   &   &    & 
+        & $\bullet$ & $\bullet$ \\
+    \func{unsetenv} &  &   &    & 
+        & $\bullet$ & $\bullet$ \\
+    \func{putenv} &  & opz.  & $\bullet$ & 
+        & $\bullet$ & $\bullet$ \\
+    \func{clearenv} &  & opz.  &    & 
+        &  &  \\
+    \hline
+  \end{tabular}
+  \caption{Funzioni per la gestione delle variabili di ambiente.}
+  \label{tab:proc_env_func}
+\end{table}
+
+In Linux solo le prime quattro funzioni di \tabref{tab:proc_env_func} sono
+definite, \func{getenv} l'abbiamo già esaminata; delle tre restanti le prime
+due, \func{putenv} e \func{setenv}, servono per assegnare nuove variabili di
+ambiente, i loro prototipi sono i seguenti:
+\begin{functions}
+  \headdecl{stdlib.h} 
+  
+  \funcdecl{int setenv(const char *name, const char *value, int overwrite)}
+  Imposta la variabile di ambiente \param{name} al valore \param{value}.
+  
+  \funcdecl{int putenv(char *string)} Aggiunge la stringa \param{string}
+  all'ambiente.
+  
+  \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 per un
+    errore, che è sempre \macro{ENOMEM}.}
+\end{functions}
+\noindent la terza, \func{unsetenv}, serve a cancellare una variabile di
+ambiente; il suo prototipo è:
+\begin{functions}
+  \headdecl{stdlib.h}
+  
+  \funcdecl{void unsetenv(const char *name)} Rimuove la variabile di ambiente
+  \param{name}.
+\end{functions}
+\noindent questa funzione elimina ogni occorrenza della variabile specificata;
+se essa non esiste non succede nulla. Non è prevista (dato che la funzione è
+\ctyp{void}) nessuna segnalazione di errore.
+
+Per modificare o aggiungere una variabile di ambiente si possono usare sia
+\func{setenv} che \func{putenv}. La prima permette di specificare
+separatamente nome e valore della variabile di ambiente, inoltre il valore di
+\param{overwrite} specifica il comportamento della funzione nel caso la
+variabile esista già, sovrascrivendola se diverso da zero, lasciandola
+immutata se uguale a zero.
+
+La seconda funzione prende come parametro una stringa analoga quella
+restituita da \func{getenv}, e sempre nella forma \var{NOME=valore}. Se la
+variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
+invece esiste il suo valore sarà impostato a quello specificato da
+\param{string}. Si tenga presente che, seguendo lo standard SUSv2, le
+\acr{glibc} successive alla versione 2.1.2 aggiungono\footnote{il
+  comportamento è lo stesso delle vecchie \acr{libc4} e \acr{libc5}; nelle
+  \acr{glibc}, dalla versione 2.0 alla 2.1.1, veniva invece fatta una copia,
+  seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite
+  di memoria e non rispetta lo standard. Il comportamento è stato modificato a
+  partire dalle 2.1.2, eliminando anche, sempre in conformità a SUSv2,
+  l'attributo \ctyp{const} dal prototipo.} \param{string} alla lista delle
+variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
+riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
+questa funzione una variabile automatica (per evitare i problemi esposti in
+\secref{sec:proc_auto_var}).
+
+Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
+variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
+carattere \texttt{'='}) allora questa viene cancellata dall'ambiente. Infine
+se la chiamata di \func{putenv} comporta la necessità di allocare una nuova
+versione del vettore \var{environ} questo sarà allocato, ma la versione
+corrente sarà deallocata solo se anch'essa è risultante da un'allocazione
+fatta in precedenza da un'altra \func{putenv}. Questo perché il vettore delle
+variabili di ambiente iniziale, creato dalla chiamata ad \func{exec} (vedi
+\secref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
+\figref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
+Inoltre la memoria associata alle variabili di ambiente eliminate non viene
+liberata.
+
+
+\section{Problematiche di programmazione generica}
+\label{sec:proc_gen_prog}
+
+Benché questo non sia un libro di C, è opportuno affrontare alcune delle
+problematiche generali che possono emergere nella programmazione e di quali
+precauzioni o accorgimenti occorre prendere per risolverle. Queste
+problematiche non sono specifiche di sistemi unix-like o multitasking, ma
+avendo trattato in questo capitolo il comportamento dei processi visti come
+entità a sé stanti, le riportiamo qui.
+
+
+\subsection{Il passaggio delle variabili e dei valori di ritorno}
+\label{sec:proc_var_passing}
+
+Una delle caratteristiche standard del C è che le variabili vengono passate
+alle subroutine attraverso un meccanismo che viene chiamato \textit{by value}
+(diverso ad esempio da quanto avviene con il Fortran, dove le variabili sono
+passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
+del passaggio può essere controllata con l'operatore \cmd{\&}).
+
+Il passaggio di una variabile \textit{by value} significa che in realtà quello
+che viene passato alla subroutine è una copia del valore attuale di quella
+variabile, copia che la subroutine potrà modificare a piacere, senza che il
+valore originale nella routine chiamante venga toccato. In questo modo non
+occorre preoccuparsi di eventuali effetti delle operazioni della subroutine
+sulla variabile passata come parametro.
+
+Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
+vale per qualunque variabile, puntatori compresi; quando però in una
+subroutine si usano dei puntatori (ad esempio per scrivere in un buffer) in
+realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
+se i puntatori sono copie, i dati a cui essi puntano sono sempre gli stessi, e
+le eventuali modifiche avranno effetto e saranno visibili anche nella routine
+chiamante.
+
+Nella maggior parte delle funzioni di libreria e delle system call i puntatori
+vengono usati per scambiare dati (attraverso buffer o strutture) e le
+variabili semplici vengono usate per specificare parametri; in genere le
+informazioni a riguardo dei risultati vengono passate alla routine chiamante
+attraverso il valore di ritorno.  È buona norma seguire questa pratica anche
+nella programmazione normale.
+
+Talvolta però è necessario che la funzione possa restituire indietro alla
+funzione chiamante un valore relativo ad uno dei suoi parametri.  Per far
+questo si usa il cosiddetto \textit{value result argument}, si passa cioè,
+invece di una normale variabile, un puntatore alla stessa; vedremo alcuni
+esempi di questa modalità nelle funzioni che gestiscono i socket (in
+\secref{sec:TCPel_functions}), in cui, per permettere al kernel di restituire
+informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
+viene usato questo meccanismo.
+
+
+\subsection{Il passaggio di un numero variabile di argomenti}
+\label{sec:proc_variadic}
+
+Come vedremo nei capitoli successivi, non sempre è possibile specificare un
+numero fisso di parametri per una funzione.  Lo standard ISO C prevede nella
+sua sintassi la possibilità di definire delle \textit{variadic function} che
+abbiano un numero variabile di argomenti, attraverso l'uso della
+\textit{ellipsis} \var{...} nella dichiarazione della funzione; ma non
+provvede a livello di linguaggio alcun meccanismo con cui dette funzioni
+possono accedere ai loro argomenti.
+
+L'accesso viene invece realizzato dalle librerie standard che provvedono gli
+strumenti adeguati.  L'uso delle \textit{variadic function} prevede tre punti:
+\begin{itemize*}
+\item \textsl{Dichiarare} la funzione come \textit{variadic} usando un
+  prototipo che contenga una \textit{ellipsis}.
+\item \textsl{Definire} la funzione come \textit{variadic} usando lo stesso
+  \textit{ellipsis}, ed utilizzare le apposite macro che consentono la
+  gestione di un numero variabile di argomenti.
+\item \textsl{Chiamare} la funzione specificando prima gli argomenti fissi, e
+  a seguire gli addizionali.
+\end{itemize*}
+
+Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
+almeno un argomento fisso; prima di effettuare la dichiarazione deve essere
+incluso l'apposito header file \file{stdarg.h}; un esempio di dichiarazione è
+il prototipo della funzione \func{execl} che vedremo in
+\secref{sec:proc_exec}:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+  int execl(const char *path, const char *arg, ...);
+\end{lstlisting}
+in questo caso la funzione prende due parametri fissi ed un numero variabile
+di altri parametri (che verranno a costituire gli elementi successivi al primo
+del vettore \var{argv} passato al nuovo processo). Lo standard ISO C richiede
+inoltre che l'ultimo degli argomenti fissi sia di tipo
+\textit{self-promoting}\footnote{il linguaggio C prevede che quando si
+  mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
+  per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
+  automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
+  \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
+  a sé stesso.} il che esclude array, puntatori a funzioni e interi di tipo
+\ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
+alcuni compilatori è di non dichiarare l'ultimo parametro fisso come
+\ctyp{register}.
+
+Una volta dichiarata la funzione il secondo passo è accedere ai vari parametri
+quando la si va a definire. I parametri fissi infatti hanno un loro nome, ma
+quelli variabili vengono indicati in maniera generica dalla ellipsis.
+
+L'unica modalità in cui essi possono essere recuperati è pertanto quella
+sequenziale; essi verranno estratti dallo stack secondo l'ordine in cui sono
+stati scritti. Per fare questo in \file{stdarg.h} sono definite delle apposite
+macro; la procedura da seguire è la seguente:
+\begin{enumerate*}
+\item Inizializzare un puntatore alla lista degli argomenti di tipo
+  \type{va\_list} attraverso la macro \macro{va\_start}.
+\item Accedere ai vari argomenti opzionali con chiamate successive alla macro
+  \macro{va\_arg}, la prima chiamata restituirà il primo argomento, la seconda
+  il secondo e così via.
+\item Dichiarare la conclusione dell'estrazione dei parametri invocando la
+  macro \macro{va\_end}.
+\end{enumerate*}
+in generale è perfettamente legittimo richiedere meno argomenti di quelli che
+potrebbero essere stati effettivamente forniti, e nella esecuzione delle
+\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
+saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
+otterranno dei valori indefiniti. Nel caso del \cmd{gcc} l'uso della macro
+\macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
+compatibilità.
+
+Le definizioni delle tre macro sono le seguenti:
+\begin{functions}
+  \headdecl{stdarg.h}
+  
+  \funcdecl{void va\_start(va\_list ap, last)} Inizializza il puntatore alla
+  lista di argomenti \param{ap}; il parametro \param{last} \emph{deve} essere
+  l'ultimo dei parametri fissi.
+  
+  \funcdecl{type va\_arg(va\_list ap, type)} Restituisce il valore del
+  successivo parametro opzionale, modificando opportunamente \param{ap}; la
+  macro richiede che si specifichi il tipo dell'argomento attraverso il
+  parametro \param{type} che deve essere il nome del tipo dell'argomento in
+  questione. Il tipo deve essere \textit{self-promoting}.
+
+  \funcdecl{void va\_end(va\_list ap)} Conclude l'uso di \param{ap}.
+\end{functions}
+
+In generale si possono avere più puntatori alla lista degli argomenti,
+ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
+e ciascuno potrà scandire la lista degli argomenti per conto suo. 
+
+Dopo l'uso di \macro{va\_end} la variabile \var{ap} diventa indefinita e
+successive chiamate a \macro{va\_arg} non funzioneranno. Si avranno risultati
+indefiniti anche chiamando \macro{va\_arg} specificando un tipo che non
+corrisponde a quello del parametro.
+
+Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
+corpo principale della funzione, il passo 2) invece può essere eseguito anche
+in una subroutine passandole il puntatore alla lista di argomenti; in questo
+caso però si richiede che al ritorno della funzione il puntatore non venga più
+usato (lo standard richiederebbe la chiamata esplicita di \macro{va\_end}),
+dato che il valore di \var{ap} risulterebbe indefinito.
+
+Esistono dei casi in cui è necessario eseguire più volte la scansione dei
+parametri e poter memorizzare una posizione durante la stessa.  La cosa più
+naturale in questo caso sembrerebbe quella di copiarsi il puntatore alla lista
+degli argomenti con una semplice assegnazione. Dato che una delle
+realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
+stack all'indirizzo dove sono stati salvati i parametri, è assolutamente
+normale pensare di poter effettuare questa operazione.
+
+In generale però possono esistere anche realizzazioni diverse, per questo
+motivo \macro{va\_list} è definito come \textsl{tipo opaco} e non può essere
+assegnato direttamente ad un'altra variabile dello stesso tipo. Per risolvere
+questo problema lo standard ISO C99\footnote{alcuni sistemi che non hanno
+  questa macro provvedono al suo posto \macro{\_\_va\_copy} che era il nome
+  proposto in una bozza dello standard.} ha previsto una macro ulteriore che
+permette di eseguire la copia di un puntatore alla lista degli argomenti:
+\begin{prototype}{stdarg.h}{void va\_copy(va\_list dest, va\_list src)}
+  Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
+  su \param{dest}.
+\end{prototype}
+\noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
+\macro{va\_copy} con una corrispondente \macro{va\_end} sul nuovo puntatore
+alla lista degli argomenti.
+
+La chiamata di una funzione con un numero variabile di argomenti, posto che la
+si sia dichiarata e definita come tale, non prevede nulla di particolare;
+l'invocazione è identica alle altre, con i parametri, sia quelli fissi che
+quelli opzionali, separati da virgole. Quello che però è necessario tenere
+presente è come verranno convertiti gli argomenti variabili. 
+
+In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
+che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
+gli opzionali), ma dato che il prototipo non può specificare il tipo degli
+argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
+dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
+\macro{va\_arg} come \ctyp{int}).
+
+Uno dei problemi che si devono affrontare con le funzioni con un numero
+variabile di argomenti è che non esiste un modo generico che permetta di
+stabilire quanti sono i parametri passati effettivamente in una chiamata.
+
+Esistono varie modalità per affrontare questo problema; una delle più
+immediate è quella di specificare il numero degli argomenti opzionali come uno
+degli argomenti fissi. Una variazione di questo metodo è l'uso di un parametro
+per specificare anche il tipo degli argomenti (come fa la stringa di formato
+per \func{printf}).
+
+Una modalità diversa, che può essere applicata solo quando il tipo dei
+parametri lo rende possibile, è quella che prevede di usare un valore speciale
+come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
+\macro{NULL} per indicare la fine della lista degli argomenti).
+
+
+\subsection{Potenziali problemi con le variabili automatiche}
+\label{sec:proc_auto_var}
+
+Uno dei possibili problemi che si possono avere con le subroutine è quello di
+restituire alla funzione chiamante dei dati che sono contenuti in una
+variabile automatica.  Ovviamente quando la subroutine ritorna la sezione
+dello stack che conteneva la variabile automatica potrà essere riutilizzata da
+una nuova funzione, con le immaginabili conseguenze di sovrapposizione e
+sovrascrittura dei dati.
+
+Per questo una delle regole fondamentali della programmazione in C è che
+all'uscita di una funzione non deve restare nessun riferimento alle variabili
+locali; qualora sia necessario utilizzare variabili che possano essere viste
+anche dalla funzione chiamante queste devono essere allocate esplicitamente, o
+in maniera statica (usando variabili di tipo \ctyp{static} o \ctyp{extern}), o
+dinamicamente con una delle funzioni della famiglia \func{malloc}.
+
+
+\subsection{Il controllo di flusso non locale}
+\label{sec:proc_longjmp}
+
+Il controllo del flusso di un programma in genere viene effettuato con le
+varie istruzioni del linguaggio C; fra queste la più bistrattata è il
+\code{goto}, che viene deprecato in favore dei costrutti della programmazione
+strutturata, che rendono il codice più leggibile e mantenibile . Esiste però
+un caso in cui l'uso di questa istruzione porta all'implementazione più
+efficiente e chiara anche dal punto di vista della struttura del programma:
+quello dell'uscita in caso di errore.
+
+Il C però non consente di effettuare un salto ad una label definita in
+un'altra funzione, per cui se l'errore avviene in una funzione e la sua
+gestione ordinaria è in un'altra occorre usare quello che viene chiamato un
+\textsl{salto non-locale}.  Il caso classico in cui si ha questa necessità,
+citato sia da \cite{APUE} che da da \cite{glibc}, è quello di un programma nel
+cui corpo principale in cui viene letto un input del quale viene eseguita,
+attraverso una serie di funzioni di analisi, una scansione dei contenuti da cui
+ottenere le indicazioni per l'esecuzione di opportune operazioni.
+
+Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
+in fasi diverse, la rilevazione di un errore nell'input può accadere
+all'interno di funzioni profondamente annidate l'una nell'altra. In questo
+caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
+all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
+successive, mentre sarebbe molto più comodo poter tornare direttamente al
+ciclo di lettura principale, scartando l'input come errato.\footnote{a meno
+  che, come precisa \cite{glibc}, alla chiusura di ciascuna fase non siano
+  associate operazioni di pulizia specifiche (come deallocazioni, chiusure di
+  file, ecc.), che non potrebbero essere eseguite con un salto non-locale.}
+
+Tutto ciò può essere realizzato salvando il contesto dello stack nel punto in
+cui si vuole tornare in caso di errore, e ripristinandolo quando l'occorrenza
+capita. La funzione che permette di salvare il contesto dello stack è
+\func{setjmp}, il cui prototipo è:
+\begin{functions}
+  \headdecl{setjmp.h}
+  \funcdecl{void setjmp(jmp\_buf env)}
+  
+  Salva il contesto dello stack in \param{env} per un successivo uso da parte
+  di \func{longjmp}. 
+
+  \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
+    valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
+    che usa il contesto salvato in precedenza.}
+\end{functions}
+
+Quando si esegue la funzione il contesto viene salvato in appositi oggetti (di
+tipo \type{jmp\_buf}), passati come primo argomento alla funzione, in genere
+questi vengono definiti come variabili globali in modo da poter essere visti
+in tutte le funzioni del programma.
+
+Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
+diverso da zero viene restituito solo quando il ritorno è dovuto ad una
+chiamata di \func{longjmp} in un'altra parte del programma. Si tenga conto che
+il contesto salvato in \param{env} viene invalidato se la routine che ha
+chiamato \func{setjmp} ritorna, nel qual caso l'uso di \func{longjmp} può
+comportare conseguenze imprevedibili (e di norma fatali per il processo).
+  
+Come accennato per effettuare un salto non-locale ad un punto precedentemente
+stabilito con \func{setjmp} si usa la funzione \func{longjmp}; il suo
+prototipo è:
+\begin{functions}
+  \headdecl{setjmp.h}
+  \funcdecl{void longjmp(jmp\_buf env, int val)}
+  
+  Ripristina il contesto dello stack salvato nell'ultima chiamata di
+  \func{setjmp} con l'argomento \param{env}.
+  
+  \bodydesc{La funzione non ritorna.}
+\end{functions}
+
+Dopo l'esecuzione della funzione programma prosegue dal 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 da zero, se si è specificato 0 sarà
+comunque restituito 1 al suo posto.
+
+In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
+di ritornare alla riga successiva della funzione chiamante, il programma
+ritorna alla posizione della relativa \func{setjmp}, ed il ritorno può essere
+effettuato anche attraverso diversi livelli di funzioni annidate.
+
+L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
+interagiscono direttamente con la gestione dello stack ed il funzionamento del
+compilatore stesso. In particolare \func{setjmp} è implementata con una macro,
+pertanto non si può cercare di ottenerne l'indirizzo, ed inoltre delle
+chiamate a questa funzione sono sicure solo in uno dei seguenti casi:
+\begin{itemize}
+\item come espressione di controllo in un comando condizionale, di selezione
+  o di iterazione (come \code{if}, \code{switch} o \code{while}).
+\item come operando per un operatore di uguaglianza o confronto in una
+  espressione di controllo di un comando condizionale, di selezione o di
+  iterazione.
+\item come operando per l'operatore di negazione (\code{!}) in una espressione
+  di controllo di un comando condizionale, di selezione o di iterazione.
+\item come espressione a sé stante.
+\end{itemize}
+
+In generale, dato che l'unica differenza fra la chiamata diretta e quella
+ottenuta da un \func{longjmp}, è il valore di ritorno di \func{setjmp}, essa è
+usualmente chiamata all'interno di un comando \code{if}. 
+
+Uno dei punti critici dei salti non-locali è quello del valore delle
+variabili, ed in particolare quello delle variabili automatiche della funzione
+a cui si ritorna. In generale le variabili globali e statiche mantengono i
+valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
+delle variabili automatiche (o di quelle dichiarate \code{register}) sono in
+genere indeterminati.
+
+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)
+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
+\code{volatile}.
+
+
 
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: