+%
+% TODO:trattare qui, quando sarà il momento vsyscall e vDSO, vedi:
+% http://davisdoesdownunder.blogspot.com/2011/02/linux-syscall-vsyscall-and-vdso-oh-my.html
+% http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
+%
+
+Inoltre alcune \textit{system call} sono state modificate nel corso degli anni
+con lo sviluppo del kernel per aggiungere ad esempio funzionalità in forma di
+nuovi argomenti, o per consolidare diverse varianti in una interfaccia
+generica. Per questo motivo dovendo utilizzare una \textit{system call} è
+sempre preferibile usare l'interfaccia fornita dalla \textsl{glibc}, che si
+cura di mantenere una uniformità chiamando le versioni più aggiornate.
+
+Ci sono alcuni casi però in cui può essere necessario evitare questa
+associazione, e lavorare a basso livello con una specifica versione, oppure si
+può voler utilizzare una \textit{system call} che non è stata ancora associata
+ad una funzione di libreria. In tal caso, per evitare di dover effettuare
+esplicitamente le operazioni di preparazione citate, all'interno della
+\textsl{glibc} è fornita una specifica funzione, \funcd{syscall}, che consente
+eseguire direttamente una \textit{system call}; il suo prototipo, accessibile
+se si è definita la macro \macro{\_GNU\_SOURCE}, è:
+
+\begin{funcproto}{
+ \fhead{unistd.h}
+ \fhead{sys/syscall.h}
+ \fdecl{int syscall(int number, ...)}
+ \fdesc{Esegue la \textit{system call} indicata da \param{number}.}
+}
+{La funzione ritorna un intero dipendente dalla \textit{system call} invocata,
+ in generale $0$ indica il successo ed un valore negativo un errore.}
+\end{funcproto}
+
+La funzione richiede come primo argomento il numero della \textit{system call}
+da invocare, seguita dagli argomenti da passare alla stessa, che ovviamente
+dipendono da quest'ultima, e restituisce il codice di ritorno della
+\textit{system call} invocata. In generale un valore nullo indica il successo
+ed un valore negativo è un codice di errore che poi viene memorizzato nella
+variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
+sez.~\ref{sec:sys_errors}).
+
+Il valore di \param{number} dipende sia dalla versione di kernel che
+dall'architettura,\footnote{in genere le vecchie \textit{system call} non
+ vengono eliminate e se ne aggiungono di nuove con nuovi numeri.} ma
+ciascuna \textit{system call} viene in genere identificata da una costante
+nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
+corrisponde anche alla omonima funzione di libreria. Queste costanti sono
+definite nel file \headfile{sys/syscall.h}, ma si possono anche usare
+direttamente valori numerici.
+
+
+\subsection{La terminazione di un programma}
+\label{sec:proc_conclusion}
+
+Normalmente un programma conclude la sua esecuzione quando si fa ritornare la
+funzione \code{main}, si usa cioè l'istruzione \instruction{return} del
+linguaggio C all'interno della stessa, o se si richiede esplicitamente la
+chiusura invocando direttamente la funzione \func{exit}. Queste due modalità
+sono assolutamente equivalenti, dato che \func{exit} viene chiamata in maniera
+trasparente anche quando \code{main} ritorna, passandogli come argomento il
+valore di ritorno (che essendo .
+
+La funzione \funcd{exit}, che è completamente generale, essendo definita dallo
+standard ANSI C, è quella che deve essere invocata per una terminazione
+``\textit{normale}'', il suo prototipo è:
+
+\begin{funcproto}{
+ \fhead{unistd.h}
+ \fdecl{void exit(int status)}
+ \fdesc{Causa la conclusione ordinaria del programma.}
+}
+{La funzione non ritorna, il processo viene terminato.}
+\end{funcproto}
+
+La funzione è pensata per eseguire una conclusione pulita di un programma che
+usi la libreria standard del C; essa esegue tutte le funzioni che sono state
+registrate con \func{atexit} e \func{on\_exit} (vedi
+sez.~\ref{sec:proc_atexit}), chiude tutti gli \textit{stream} (vedi
+sez.~\ref{sec:file_stream}) effettuando il salvataggio dei dati sospesi
+(chiamando \func{fclose}, vedi sez.~\ref{sec:file_fopen}), infine passa il
+controllo al kernel chiamando la \textit{system call} \func{\_exit} (che
+vedremo a breve) che completa la terminazione del processo.
+
+\itindbeg{exit~status}
+
+Il valore dell'argomento \param{status} o il valore di ritorno di \code{main},
+costituisce quello che viene chiamato lo \textsl{stato di uscita}
+(l'\textit{exit status}) del processo. In generale si usa questo valore per
+fornire al processo padre (come vedremo in sez.~\ref{sec:proc_wait}) delle
+informazioni generiche sulla riuscita o il fallimento del programma appena
+terminato.
+
+Anche se l'argomento \param{status} (ed il valore di ritorno di \code{main})
+sono numeri interi di tipo \ctyp{int}, si deve tener presente che il valore
+dello stato di uscita viene comunque troncato ad 8 bit,
+per cui deve essere sempre compreso fra 0 e 255. Si tenga presente che se si
+raggiunge la fine della funzione \code{main} senza ritornare esplicitamente si
+ha un valore di uscita indefinito, è pertanto consigliabile di concludere
+sempre in maniera esplicita detta funzione.
+
+Non esiste un valore significato intrinseco della stato di uscita, ma una
+convenzione in uso pressoché universale è quella di restituire 0 in caso di
+successo e 1 in caso di fallimento. Una eccezione a questa convenzione è 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. 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é le convenzioni citate non siano seguite universalmente è
+una buona idea tenerle presenti ed adottarle a seconda dei casi.
+
+Si tenga presente inoltre che non è una buona idea usare eventuali codici di
+errore restituiti nella variabile \var{errno} (vedi sez.~\ref{sec:sys_errors})
+come \textit{exit status}. In generale infatti non ci si cura del valore dello
+stato di uscita di un processo se non per vedere se è diverso da zero, come
+indicazione di un qualche errore. Dato che viene troncato ad 8 bit utilizzare
+un intero di valore generico può comportare il rischio, qualora si vada ad
+usare un multiplo di 256, di avere uno stato di uscita uguale a zero, che
+verrebbe interpretato come un successo.
+
+Per questo motivo in \headfile{stdlib.h} sono definite, seguendo lo standard
+POSIX, le due costanti \const{EXIT\_SUCCESS} e \const{EXIT\_FAILURE}, da usare
+sempre per specificare lo stato di uscita di un processo. Su Linux, ed in
+generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente i
+valori 0 e 1.
+
+\itindend{exit~status}
+
+Una forma alternativa per effettuare una terminazione esplicita di un
+programma è quella di chiamare direttamente la \textit{system call}
+\funcd{\_exit},\footnote{la stessa è definita anche come \funcd{\_Exit} in
+ \headfile{stdlib.h}.} che restituisce il controllo direttamente al kernel,
+concludendo immediatamente il processo, il suo prototipo è:
+
+\begin{funcproto}{ \fhead{unistd.h} \fdecl{void \_exit(int status)}
+ \fdesc{Causa la conclusione immediata del programma.} } {La funzione non
+ ritorna, il processo viene terminato.}
+\end{funcproto}
+
+La funzione termina immediatamente il processo e le eventuali funzioni
+registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. La
+funzione chiude tutti i file descriptor appartenenti al processo, cosa che
+però non comporta il salvataggio dei dati eventualmente presenti nei buffer
+degli \textit{stream}, (torneremo sulle due interfacce dei file in
+sez.~\ref{sec:file_unix_interface} e
+sez.~\ref{sec:files_std_interface}). Infine fa sì che ogni figlio del processo
+sia adottato da \cmd{init} (vedi sez.~\ref{sec:proc_termination}), manda un
+segnale \signal{SIGCHLD} al processo padre (vedi
+sez.~\ref{sec:sig_job_control}) e ritorna lo stato di uscita specificato
+in \param{status} che può essere raccolto usando la funzione \func{wait} (vedi
+sez.~\ref{sec:proc_wait}).
+
+Si tenga presente infine che oltre alla conclusione ``\textsl{normale}''
+appena illustrata esiste anche la possibilità di una conclusione
+``\textsl{anomala}'' del programma a causa della ricezione di un segnale
+(tratteremo i segnali in cap.~\ref{cha:signals}) o della chiamata alla
+funzione \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
+
+
+\subsection{Esecuzione di funzioni preliminari all'uscita}
+\label{sec:proc_atexit}
+
+Un'esigenza comune che si incontra è 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 fare 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 di funzioni che verranno eseguite all'uscita dal
+programma,\footnote{nel caso di \func{atexit} lo standard POSIX.1-2001
+ richiede che siano registrabili almeno \const{ATEXIT\_MAX} funzioni (il
+ valore può essere ottenuto con \func{sysconf}, vedi
+ sez.~\ref{sec:sys_limits}).} sia per la chiamata ad \func{exit} che per il
+ritorno di \code{main}. La prima funzione che si può utilizzare a tal fine è
+\funcd{atexit}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int atexit(void (*function)(void))}
+\fdesc{Registra la funzione \param{function} per la chiamata all'uscita
+ dal programma.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
+ non viene modificata.}
+\end{funcproto}
+
+La funzione richiede come argomento \param{function} l'indirizzo di una
+opportuna funzione di pulizia da chiamare all'uscita del programma, che non
+deve prendere argomenti e non deve ritornare niente. In sostanza deve la
+funzione di pulizia dovrà essere definita come \code{void function(void)}.
+
+Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
+\acr{glibc} includono per compatibilità con SunOS ma che non è detto sia
+definita su altri sistemi,\footnote{non essendo prevista dallo standard POSIX
+ è in genere preferibile evitarne l'uso.} il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int on\_exit(void (*function)(int, void *), void *arg))}
+\fdesc{Registra la funzione \param{function} per la chiamata all'uscita dal
+ programma.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
+ non viene modificata.}
+\end{funcproto}
+
+In questo caso la funzione da chiamare all'uscita prende i due argomenti
+specificati nel prototipo, un intero ed un puntatore; dovrà cioè essere
+definita come \code{void function(int status, void *argp)}. Il primo argomento
+sarà inizializzato allo stato di uscita con cui è stata chiamata \func{exit}
+ed il secondo al puntatore \param{arg} passato come secondo argomento di
+\func{on\_exit}. Così diventa possibile passare dei dati alla funzione di
+chiusura.
+
+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. Siccome entrambe le funzioni
+\func{atexit} e \func{on\_exit} fanno riferimento alla stessa lista, l'ordine
+di esecuzione sarà riferito alla registrazione in quanto tale,
+indipendentemente dalla funzione usata per farla.
+
+Una volta completata l'esecuzione di tutte le funzioni registrate verranno
+chiusi tutti gli \textit{stream} aperti ed infine verrà chiamata \func{\_exit}
+per la terminazione del programma. Questa è la sequenza ordinaria, eseguita a
+meno che una delle funzioni registrate non esegua al suo interno
+\func{\_exit}, nel qual caso la terminazione del programma sarà immediata ed
+anche le successive funzioni registrate non saranno invocate.
+
+Se invece all'interno di una delle funzioni registrate si chiama un'altra
+volta \func{exit} lo standard POSIX.1-2001 prescrive un comportamento
+indefinito, con la possibilità (che su Linux comunque non c'è) di una
+ripetizione infinita. Pertanto questa eventualità è da evitare nel modo più
+assoluto. Una altro comportamento indefinito si può avere se si termina
+l'esecuzione di una delle funzioni registrate con \func{longjmp} (vedi
+sez.~\ref{sec:proc_longjmp}).
+
+Si tenga presente infine che in caso di terminazione anomala di un processo
+(ad esempio a causa di un segnale) nessuna delle funzioni registrate verrà
+eseguita e che se invece si crea un nuovo processo con \func{fork} (vedi
+sez.~\ref{sec:proc_fork}) questo manterrà tutte le funzioni già registrate.
+
+
+\subsection{Un riepilogo}