+Un esempio di inclusione di questi file, preso da uno dei programmi di
+esempio, è il seguente, e si noti come gli \textit{header file} possano essere
+referenziati con il nome fra parentesi angolari, nel qual caso si indica l'uso
+di quelli installati con il sistema,\footnote{in un sistema GNU/Linux che
+ segue le specifiche del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
+ \textit{Filesystem Hierarchy Standard} (per maggiori informazioni si
+ consulti sez.~1.2.3 di \cite{AGL}) si trovano sotto \texttt{/usr/include}.}
+o fra virgolette, nel qual caso si fa riferimento ad una versione locale, da
+indicare con un \itindsub{pathname}{relativo} \textit{pathname} relativo:
+\includecodesnip{listati/main_include.c}
+
+Si tenga presente che oltre ai nomi riservati a livello generale di cui si è
+parlato in sez.~\ref{sec:proc_main}, alcuni di questi \textit{header file}
+riservano degli ulteriori identificativi, il cui uso sarà da evitare, ad
+esempio si avrà che:
+\begin{itemize*}
+\item in \headfile{dirent.h} vengono riservati i nomi che iniziano con
+ ``\texttt{d\_}'' e costituiti da lettere minuscole,
+\item in \headfile{fcntl.h} vengono riservati i nomi che iniziano con
+ ``\texttt{l\_}'', ``\texttt{F\_}'',``\texttt{O\_}'' e ``\texttt{S\_}'',
+\item in \headfile{limits.h} vengono riservati i nomi che finiscono in
+ ``\texttt{\_MAX}'',
+\item in \headfile{signal.h} vengono riservati i nomi che iniziano con
+ ``\texttt{sa\_}'' e ``\texttt{SA\_}'',
+\item in \headfile{sys/stat.h} vengono riservati i nomi che iniziano con
+ ``\texttt{st\_}'' e ``\texttt{S\_}'',
+\item in \headfile{sys/times.h} vengono riservati i nomi che iniziano con
+ ``\texttt{tms\_}'',
+\item in \headfile{termios.h} vengono riservati i nomi che iniziano con
+ ``\texttt{c\_}'', ``\texttt{V}'', ``\texttt{I}'', ``\texttt{O}'' e
+ ``\texttt{TC}'' e con ``\texttt{B}'' seguito da un numero,
+\item in \headfile{grp.h} vengono riservati i nomi che iniziano con
+ ``\texttt{gr\_}'',
+\item in \headfile{pwd.h}vengono riservati i nomi che iniziano con
+ ``\texttt{pw\_}'',
+\end{itemize*}
+
+\itindend{header~file}
+
+Una volta inclusi gli \textit{header file} necessari un programma potrà
+richiamare le funzioni di libreria direttamente nel proprio codice ed accedere
+ai servizi del kernel; come accennato infatti normalmente ogni \textit{system
+ call} è associata ad una omonima funzione di libreria, che è quella che si
+usa normalmente per invocarla.
+
+Occorre però tenere presente che anche se dal punto di vista della scrittura
+del codice la chiamata di una \textit{system call} non è diversa da quella di
+una qualunque funzione ordinaria, la situazione è totalmente diversa
+nell'esecuzione del programma. Una funzione ordinaria infatti viene eseguita,
+esattamente come il codice che si è scritto nel corpo del programma, in
+\textit{user space}. Quando invece si esegue una \textit{system call}
+l'esecuzione ordinaria del programma viene interrotta, i dati forniti (come
+argomenti della chiamata) vengono trasferiti al kernel che esegue il codice
+della \textit{system call} (che è codice del kernel) in \textit{kernel space}.
+
+Dato che il passaggio dei dati ed il salvataggio del contesto di esecuzione
+del programma che consentirà di riprenderne l'esecuzione ordinaria al
+completamento della \textit{system call} sono operazioni critiche per le
+prestazioni del sistema, per rendere il più veloce possibile questa
+operazione, usualmente chiamata \textit{context switch} sono state sviluppate
+una serie di ottimizzazioni che richiedono alcune preparazioni abbastanza
+complesse dei dati, che in genere dipendono dall'architettura del processore
+sono scritte direttamente in \textit{assembler}.
+
+%
+% 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
+cap.~\ref{cha:files_std_interface} e
+cap.~\ref{cha:file_unix_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